ドメイン駆動型設計を実装する際に、工場で他の集約を参照できますか？

Question

私は2つの凝集体、EmployeeとCompanyを持っています。 EmployeeはCompanyへの参照をUUIDで保存します。

私は従業員を作成したい場合は、私は会社のIDとそれを提供する必要があります。

new Employee(name, companyId) 

私の周り私の頭を取得することはできませんどのようなクライアント場合Companyのidを取得する方法です会社名のみを提供します。言い換えれば、私はこの出来事を参照してください。今、私はEmployeeを作成するためにCompany集約への依存性を導入してきたように

Employee buildEmployee(String name, String companyName) { 
    Company company = companyRepository.findByName() 
    return new Employeee(name, company.getGUID()) 
} 

何かが、私には間違って感じています。さらに悪いのは、これらが2つのマイクロサービスであった場合、私は会社名を取得するために休憩をとる必要があるからです。

このカップリングを回避する方法はありますか、またはエンティティが正しくモデル化されていませんか？

Answer 1

は、すべての従業員は、1つの会社のために働く

です。

これで、従業員を作成する前に会社が存在することが絶対に明らかです。

私はここに合うことができる二つの異なる解決策を参照してください。buildEmployeeに会社を渡し

• を。これは従業員を作成するという事実を伝えますはが必要です。

• 会社のGUIDを渡します。これは、既にこの情報を持っている場合に適していますが、既存の従業員の同僚を作成するなど、会社のオブジェクト全体を利用できるわけではありません。

あなたが取るアプローチどんなに、あなたは、工場内からリポジトリ経由のデータのロードを避ける必要があります。アプリケーションサービスは、とにかく（例えば、何らかの入力検証を行うために）会社を必要とするかもしれないので、これを呼び出すアプリケーションサービスのために残しておく方が良いです。

アプリケーションサービスですべてのリポジトリとのやりとりを維持すると、アプリケーションの堅牢性と理由が簡単になります。結局のところ、リポジトリへのアクセスには通常、ネットワークのやりとりや遅延が伴います

したがって、会社に依存することには何も問題はありません。buildEmployeeですが、リポジトリを呼び出すことは避けてください。

会社によってはまだ間違っていると感じる場合は、モデルを再検討する必要があります。

Answer 2

最初に、あなたのモデルにいくつか考えました。従業員が正確にの会社で働いていることを確かめてください。そして、この会社は変わることはありませんか？

あなたの本当の疑問について、私は本当の問題を見ません。 「DDD quickly」から引用させていただきます。

オブジェクトの構築がより複雑な場合があります。 ...

集計全体を作成するタスクが与えられ、集計のために強制する必要があるルール、制約、不変条件が含まれている特別なFactoryクラスを使用することが適切なようです有効である。オブジェクトは単純なままであり、複雑な構築ロジックが混乱することなく、特定の目的に役立ちます。

解決策の1つに、別のレイヤーを追加する方法があります。会社のUUIDで直接buildEmployee（）メソッドを呼び出します。あなたのモデルは、現在表現何

Answer 3

は、が消費コード（アプリケーションサービス）から別の集合体がテーブルに持ち込まれ、現在のトランザクションで使用されていることを隠しているため、一般的には良い考えではありません。

しかし、それは別の集計を持ち込むことは必ず悪いことではありません。

• は、あなたが実際に新しいEmployee作成するビジネストランザクションの一部であることをCompanyを必要とすることができる：あなたは、教育を受けて意思決定を行う必要があります。 Companyに従業員に関するドメイン不変条件（ユニークな従業員電子メールのリストなど）があるか、またはEmployeeを作成するとCompanyの内部で変更され、従業員の同時作成が会社内で混乱するのを防ぐ必要があるからです。

  これを行うにはいくつかの方法がありますが、2つが結びついているため、会社自体にcreateEmployee()メソッドを持たせることをお勧めします。

• Employeeを作成するときは、Company（ID以外）は気にしないでください。あなたは、既存の会社と従業員の間に一貫した一貫性を必要としないと考えることができます。データベースに外部キーがある場合、孤立した従業員が作成されないようにセキュリティが十分に提供されていることが前提です。

  その場合は、企業IDだけをUIからドメインまで、会社の唯一のポインタとして保持してください。プロセスに関与していないため、CompanyRepositoryを使用する必要はありません。