設計判断を属人化させないために、DDDの判断フローをWebアプリにしてみた

ここでいう「方式」は、単にアーキテクチャ名を選ぶことではありません。書籍で扱われる業務ロジックの実装方法や技術方式を踏まえて、業務ロジックをどこに置くか、どのアーキテクチャで支えるか、どのテスト方針で守るかをまとめて判断する、という意味で使っています。 どちらも、入力条件に基づいて判断材料を整理するためのツールです。 設計の正解を自動で出すものではありません。ドメイン駆動設計の考え方を参考にした非公式の判断支援ツールです。 新しく方式を決めるときと、既存設計を見直すときに使う 設計判断で混ざりやすいのは、「これから何を採用するか」と「いまの設計をどう変えるか」です。 新規開発では選びやすい方式でも、既存設計がある場合は、既存データ、公開API、切り戻し、段階移行まで含めて判断する必要があります。 そのため新規の方式選定では、業務領域、業務ロジックの置き方、アーキテクチャ、テスト方針を整理し

[hasiduki]

へーへーへー！！！！！！！！！

[nguyen-oi]

用語先行になりがちなDDDを、観察できる事実ベースで判断フローに落とすのアプローチとして最高

[masatotoro]

本読んでると面白い