ドメインドリブンデザインは、それほど複雑ではないドメインに対して有用/生産的ですか？

作業中の潜在的なプロジェクトを評価するとき、ドメイン駆動型の設計アプローチをそのオブジェクトモデルに使用することが有利である可能性があることを提案しました。プロジェクトには過度に複雑なドメインがないため、同僚がこれを投げました。

DDDは、複雑なドメインモデルがある場合に有利であると言われています（「...複雑で複雑なドメインで運用している場合は常に適用されます」Eric Evans）。

私が失ったものは-ドメインの複雑さをどのように定義するのですか？ドメインモデルの集約ルートの数で定義できますか？オブジェクトの相互作用におけるドメインの複雑さはありますか？

私たちが評価しているドメインは、関連するオンライン出版とコンテンツ管理です。

ビジネスロジックの複雑さは、アプリケーションの動作とも呼ばれ、最も重要な要素です。2番目に重要な要因は、DDDはビジネスチームとエンジニアリングチームの間で共有語彙を作成することであるため、技術的な問題とその問題を説明するために使用されるビジネス語彙との間にどれだけのギャップがあるかです。

DDDで使用されるパターンのいくつかは、一般的に、リポジトリパターン、バウンドコンテキスト、レイヤードアーキテクチャなどのエンタープライズアプリケーションアーキテクチャで役立ちます。これらのパターンを使用しているからといって、ドメイン駆動設計を行っているわけではありません。

それほど多くの動作がない場合、つまり、ほとんどの場合データを保存していて、そのデータを操作していない場合、そのドメインレイヤーを構築することの価値ははるかに低くなる可能性があります。コンテンツ管理で、承認と公開のみを行う場合は、ドメインメソッドではなく、システム内のフラグで表すことができます。しかし、追加の動作を追加し始めると、フルオンドメインレイヤーの適切性がより明確になります。

コンテンツ管理について話している場合、DDDの必要性を示唆し始めるかもしれないいくつかの（想像された）ルールがあります：

• ストーリーが日付xx / yy / zzまで禁輸されている場合は、印刷するために公開してから、Webに公開します 禁輸措置がない場合は、ウェブに公開して印刷可能にします
• このストーリーを有料の購読者がすぐにペイウォールの背後で利用できるようにします。2週間後に一般に公開します。
• ストーリーが作成されたら、編集、校正、承認のためにエディターに送信します。承認されたら、実稼働環境に送信します。制作がスペース上の理由でストーリーを分割する場合、拡張バージョンをオンラインで利用可能にします。