- do_M_gaToru
- 2886
- 9
- 1
- 0
ドメイン駆動設計を理解する3つのキーワード ・ドメインロジック ビジネスルール ・ドメインモデル 計算モデル(8割くらいのサブセット) ・オブジェクト指向 型指向のプログラミング #devlove
2019-03-22 19:57:12・ソフトウェアが複雑になる理由 ビジネスルールの1つ1つは単純 ルールを適用する条件分岐で複雑になる どこに適用すれば、安全で楽になるかを考えるのは難しい #devlove
2019-03-22 19:58:56ビジネスルールそのものはシンプルなことが殆どで、大変なのは、ビジネスルールを適用する条件分岐が複雑さの根源であることが多い #devlove
2019-03-22 19:58:59ビジネスルール自体が複雑ではなく、適用する条件による分岐が複雑である。 そうなんだよね、変な区分とか増えまくることがよくある。 #devlove
2019-03-22 19:59:34Springでいうと、🍥Controller・🍥Service・🍥Repositoryにビジネスルールを書かない。ビジネスルールは単独のモジュールとして分離する #devlove
2019-03-22 20:00:39アーキテクチャ論でDDDについて語られることが多いけれど、それは準備。ビジネルスール文らしきものをピュアな状態で一箇所にまとめる(=ドメイン層)のが最初のステップ。 #devlove
2019-03-22 20:00:48ビジネスルールをピュアな状態で抜き出してモジュール化することがドメイン工藤設計の最初の準備 #devlove
2019-03-22 20:01:10・入出力からビジネスルールの記述を独立させる ドメイン層に複雑さを集めただけ 入出力のノイズがないぶん戦いやすくなる 他の層がシンプルになる -> 自動生成で良いのでは? #devlove
2019-03-22 20:01:24たしかに普段の業務も処理そのものは難しくないはずなのに、条件が複雑に絡んでいるよね。 #devlove
2019-03-22 20:02:00#devlove に来ました (@ 株式会社 クラウドワークス - @crowdworksjp in 渋谷区, 東京都) swarmapp.com/c/7oS2KYhQvuM
2019-03-22 20:02:51・トランザクションスクリプト ビジネスルールがあちこちに分散して、重複する 機能単位の手順で書いたら、共通のビジネスルールを使うのは必然 #devlove
2019-03-22 20:02:55ソフトウェアにおけるモデリングでは「抽象化」よりも「分離」の方が効能の実感がある。注文という抽象クラスを作って受注・発注クラスをそれぞれ作るとうまくいくかというと疑問。受注は受注だし、発注は発注。それを分離するのが大事 #devlove
2019-03-22 20:05:27「受注」と「発注」を汎化して「注文」とすることはいいが、それを実際のプログラミングで注文クラスを継承して受注クラスと発注クラスを作るかどうかは別の話 #devlove
2019-03-22 20:05:59