domain-driven-design - DDDのどこにビジネスロジックを配置するか

Question

私は、保守とテストが容易なアーキテクチャを構築するための最良の方法を見つけようとしています。いくつかのプロジェクトを経て、私はいくつかのかなり悪いアーキテクチャを見てきました、そして私は自分のプロジェクトで将来の間違いを犯さないようにしたいと思います。

かなり複雑な3層アプリケーションを構築していて、DDDを使用したいとします。私の質問は、ビジネスロジックをどこに配置すればよいかということです。一部の人々は、それをサービス（サービス層）に配置する必要があると言いますが、それは理にかなっています。単一責任の原則に準拠した多数のサービスを持つことは理にかなっています。

ただし、これはアンチパターンであり、ビジネスロジックをサービス層に実装するべきではないと言う人もいます。どうしてこれなの？

署名付きIAuthenticationServiceのメソッドがあるとしましょう。bool UsernameAvailable(string username)このメソッドは、ユーザー名が使用可能かどうかを確認するために必要なすべてのロジックを実装します。

「これはアンチパターンです」という群衆によると、ここでの問題は何ですか？

Answer 1

すべてのビジネスロジックを（暗黙的にステートレスな）サービスレイヤーに配置すると、手続き型コードを記述していることになります。動作をデータから切り離すことで、オブジェクト指向コードの記述をあきらめることになります。

それは必ずしも悪いことではありません。それは単純であり、単純なビジネスロジックがある場合は、本格的なオブジェクト指向ドメインモデルに投資する理由はありません。

ビジネスロジックが複雑になるほど（そしてドメインが大きくなるほど）、手続き型コードがスパゲッティコードに変わるのが速くなります。手続きは、異なる事前条件と事後条件で（互換性のない順序で）相互に呼び出しを開始し、成長し続ける状態を必要とし始めます。オブジェクト。

貧血ドメインモデルに関するMartinFowlerの記事は、人々がビジネスロジックをサービス層に配置することに反対する理由（およびその条件下）を理解するための最良の出発点となるでしょう。

Answer 2

サービスレイヤー自体はアンチパターンではなく、ビジネスロジックの特定の要素を配置するための非常に合理的な場所です。ただし、サービスレイヤーの設計には慎重を期して、ドメインモデルとそれを構成するオブジェクトからビジネスロジックを盗まないようにする必要があります。

そうすることで、真のアンチパターン、貧血ドメインモデルになってしまう可能性があります。これについては、MartinFowlerがここで詳しく説明しています。

IAuthenticationServiceの例は、問題を議論するのにおそらく最適ではありません。認証に関するロジックの多くは、サービス内に存在し、ドメインオブジェクトに実際には関連付けられていないと見なすことができます。より良い例は、ユーザーを検証するためのある種のIUserValidationServiceがある場合、またはさらに悪いことに、注文の処理などを行うサービスがある場合です。検証サービスはユーザーオブジェクトからロジックを取り除き、注文処理サービスは注文オブジェクト、および場合によっては顧客、納品通知などを表すオブジェクトからも。

Answer 3

DDDには、プレゼンテーション、アプリケーション、ドメイン、インフラストラクチャの4つのレイヤーが必要です。

プレゼンテーション層は、ユーザーに情報を提示し、ユーザーコマンドを解釈します。

ユースケースロジック（アプリケーションエンティティ、アプリケーションワークフローコンポーネント、たとえばDTO、アプリケーションサービス）に依存するものはすべて、アプリケーション層（アプリケーションロジック）に送られます。このレイヤーにはビジネスロジックが含まれておらず、ビジネスオブジェクトの状態を保持せず、アプリケーションタスクの進行状況を保持できます。

ユースケースロジック（ビジネスエンティティ、ビジネスワークフローコンポーネント、ドメインモデル、ドメインサービスなど）に不変なものはすべて、ドメインレイヤー（ドメインロジック）に送られます。この層は、ビジネスドメインとビジネスルールの概念を担当します。

インフラストラクチャレイヤーには、IoC、キャッシュ、リポジトリ、ORM、暗号化、ロギング、検索エンジンなどが含まれる場合があります。