DDD 元素的确切关注点和职责

Question

我看到很多关于 DDD 的文章以及 Martin Fowler 所著的“企业应用程序架构模式”一书中描述的许多模式，但我需要有关 stackoverflow 的开发专家帮助理解一些事情。

每个 DDD 组件（如（存储库、聚合根）中应该包含的主要（方法和功能主义者）=关注点是什么？是否应该将其委托给其他对象？

聚合根对象 例如。 FaceBook , User 是一个聚合根，包含 UserObject(you)、postObjects(你创建的帖子)、pictureOBJects 的对象； WORD Holds 是否意味着它将其保持在其内部状态？或者只是它拥有一个函数，可以将您引导到另一个存储库方法，例如包括您的 id？

因为如果 Aggregate 根在其内部状态中保存聚合对象，那么当一个对象需要超过 1 个根时会发生什么？ （图片也属于photoGallery），，，grrrrr我很困惑！

请描述例如 Facebook（或任何其他 web 应用程序）域设计，以便像我这样的菜鸟可以在专家开发人员和我们之间建立一种通用语言:)

Answer 1

如果聚合根在其内部保存聚合对象 状态那么当一个对象需要超过 1 个根时会发生什么？ （图片也属于photoGallery），，，grrrrr我很困惑！

在 DDD 中，实体并不总是聚合的一部分。许多聚合根共享的一些实体是它们自己聚合的根。就像任何聚合根一样，它们有自己的存储库。例如，在蓝皮书中，Customer、Location 和 CarrierMovement 是共享实体，它们是它们自己聚合的根。

请描述例如 Facebook（或任何其他 webapp）域 设计让像我这样的菜鸟可以在两者之间建立一种无处不在的语言 专家开发人员和我们:)

DDD 模式不能盲目或平等地应用于任何应用，它们取决于您和您的团队如何看待域。例如，您不应该仅仅因为模型中存在包含关系而使用聚合模式。您可以设计：Customer 拥有 Invoice，但您也可以（更有可能）设计：Invoice 引用 Customer。两者在 DDD 中都有效。

您的设计应该真正反映您的应用程序的领域。它应该与您的领域专家的观点相匹配。领域专家可以是您自己、您的客户或您雇用的人，因为她是特定领域的专家（例如：会计、医疗保健、银行等）。在您的团队中拥有领域专家是应用 DDD 的必要条件。如果您的域不够复杂，则不需要 DDD。