面白かった
内製じゃないとDDDは難しそうですね
DDDの本質理解してない人しかフロントエンドの世界にDDDを持ち込まなそうではある
redux時代はstoreにjsonシリアライズ可能なオブジェクトしか突っ込んじゃいけないと言う話があったけど、そういう意味でクラスのインスタンスをstateに入れるのって良かったんだっけ。hooksで表現した方が良さそう。
カプセル化と関心事の分離の話。ところでこの結婚式場は飲酒運転を強制するバグがあるし、テストもバグっている。手法以前に例はちゃんとした方がいいと思われる。/修正されたようだが訂正記録が無い。
本気でドメインを理解しようとしてれば車で来た人にだけ酒の提供を可能とするようなロジックを書くはずがない。どっかから借りてきた方法論ではなくどうやったらそういう誤解をしないようになるかに注力して欲しい
車以外ではなく提供してもよい状態であるかで厳密に判定。Guestはserveされる側なのでServeする側の料飲ドメインに。Guestは料飲ドメインの判定結果だけを持つ。
いやそこでダメな例として書かれてるビジネスロジックの散在の話なんてDDDなんて関係なくごく一般的な設計セオリーの話なのでは？本当にDDDしたいならシステム全体で考えるべきだしDDD言いたいだけに見えてしまう。
この記事会社の評価だいぶ下げてしまわないか。婚礼業界・TAIAN(大安)、と会社名もしっかり覚えちゃったし。
Reactを使っているのに関心の分離でクラスを宣言してしまっている時点で色々と察する
DDDとか言い出すやつはマジで信用しない。
DDDって言葉が浸透するまで関心の分離の重要性が主張されなかったから"DDD"と丸めたい気持ちわかる。業務ドメインじゃなきゃDDDじゃないも大きな勘違い。ドメインモデルを定義してアプリに徹底すれば間違ってない原書
この講演が良かった https://www.youtube.com/watch?v=HH8h8PJJcbk https://speakerdeck.com/twada/why-the-clean-architecture-does-not-fit-with-web-frontend
フロントエンドDDD
面白かった
内製じゃないとDDDは難しそうですね
DDDの本質理解してない人しかフロントエンドの世界にDDDを持ち込まなそうではある
redux時代はstoreにjsonシリアライズ可能なオブジェクトしか突っ込んじゃいけないと言う話があったけど、そういう意味でクラスのインスタンスをstateに入れるのって良かったんだっけ。hooksで表現した方が良さそう。
カプセル化と関心事の分離の話。ところでこの結婚式場は飲酒運転を強制するバグがあるし、テストもバグっている。手法以前に例はちゃんとした方がいいと思われる。/修正されたようだが訂正記録が無い。
本気でドメインを理解しようとしてれば車で来た人にだけ酒の提供を可能とするようなロジックを書くはずがない。どっかから借りてきた方法論ではなくどうやったらそういう誤解をしないようになるかに注力して欲しい
車以外ではなく提供してもよい状態であるかで厳密に判定。Guestはserveされる側なのでServeする側の料飲ドメインに。Guestは料飲ドメインの判定結果だけを持つ。
いやそこでダメな例として書かれてるビジネスロジックの散在の話なんてDDDなんて関係なくごく一般的な設計セオリーの話なのでは？本当にDDDしたいならシステム全体で考えるべきだしDDD言いたいだけに見えてしまう。
この記事会社の評価だいぶ下げてしまわないか。婚礼業界・TAIAN(大安)、と会社名もしっかり覚えちゃったし。
Reactを使っているのに関心の分離でクラスを宣言してしまっている時点で色々と察する
DDDとか言い出すやつはマジで信用しない。
DDDって言葉が浸透するまで関心の分離の重要性が主張されなかったから"DDD"と丸めたい気持ちわかる。業務ドメインじゃなきゃDDDじゃないも大きな勘違い。ドメインモデルを定義してアプリに徹底すれば間違ってない原書
この講演が良かった https://www.youtube.com/watch?v=HH8h8PJJcbk https://speakerdeck.com/twada/why-the-clean-architecture-does-not-fit-with-web-frontend