• コードが荒れていれば変更頻度が低いのでエンジニアの反応は少ない ◦ コアサブドメインほど深刻な影響はない ◦ > You don’t have to identify all of the core subdomains. ※ おそらく supporting subdomains の誤記 ◦ 中規模の企業でもすべて特定するのは現実的ではない ◦ その代わりに... ✅ 全体的な構造を把握する ✅ 担当するシステムに最も関連性の高いサブドメインに注意を払う
何らかの理由で戦術的パターンが上手く機能しないかもしれない • 他のデザパタが特定のドメインでうまく機能するとしたら、それで問題ない “As long as you analyze your business domain and its strategy, look for effective models to solve particular problems, and most importantly, make design decisions based on the business domain’s needs: that’s domain-driven design! It’s worth reiterating that domain-driven design is not about aggregates or value objects. Domain-driven design is about letting your business domain drive software design decisions.” ビジネスドメインとその戦略を分析し、特定の問題を解決するための効果的なモデルを探し、そして最も重要なこと、ビジネスド メインの要求に基づいて設計を決める限り、それはドメイン駆動設計です! ドメイン駆動設計とは集約や値オブジェクトのことではないと、改めて強調しておきます。ドメイン駆動設計とは、ビジネスドメイ ンにソフトウェアの設計上の意思決定をさせることです。
すべてのビジネスロジックを Event sourced domain model にリファクタする B. 組織のビジネスドメインとその戦略を分析する C. システムコンポーネントが適切な Bounded contexts の原則に従うように改善する D. Brownfield PJ で DDD を使うことは不可能
すべてのビジネスロジックを Event sourced domain model にリファクタする B. 組織のビジネスドメインとその戦略を分析する C. システムコンポーネントが適切な Bounded contexts の原則に従うように改善する D. Brownfield PJ で DDD を使うことは不可能
クタすることが一般的に良くないのはなぜか? A. State-base のモデルは、学習プロセス中に集約の境界をリファクタすることを容易にする B. 大きな変更は徐々に導入する方が安全 C. AとBの両方 D. 上記のどれでもない。Transaction Script でさえ、Event sourced domain model にその ままリファクタリングするのは合理的
クタすることが一般的に良くないのはなぜか? A. State-base のモデルは、学習プロセス中に集約の境界をリファクタすることを容易にする B. 大きな変更は徐々に導入する方が安全 C. AとBの両方 D. 上記のどれでもない。Transaction Script でさえ、Event sourced domain model にその ままリファクタリングするのは合理的