DDD要素的确切问题和责任

时间:2014-03-20 16:07:11

标签: oop object domain-driven-design aggregateroot

我看到很多关于DDD的文章和“企业应用程序架构的模式”中描述的许多模式作者:Martin Fowler一书,但我需要开发GURUS在stackoverflow上帮助理解一些事情。

什么是主要的(方法和功能主义者)=应该包含在每个DDD组件中的关注点(存储库,聚合根),它应该将它委托给其他对象吗?

聚合根对象 例如。 FaceBook,User是一个聚合根,它包含UserObject(you),postObjects(你创建的帖子),pictureOBJects的对象; WORD Holds是否意味着它处于内部状态?或者只是它持有一个函数,指导你到另一个包含你的id的Repository方法?

如果聚合根保持聚合对象处于其内部状态,那么当一个对象需要超过1个根时会发生什么? (图片也属于photoGallery),,, grrrrr我很困惑!

请描述Facebook(或任何其他webapp)域名设计,以便像我这样的新手可以在专家开发者和我们之间建立无处不在的语言:)

1 个答案:

答案 0 :(得分:0)

  

导致聚合根在其内部保留聚合对象   状态然后当超过1个根需要一个对象时会发生什么?   (图片也属于photoGallery),,, grrrrr我很困惑!

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

  

请描述Facebook(或任何其他webapp)域名   设计所以像我这样的新手可以建立一种无所不在的语言   专家开发人员和我们:)

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

您的设计应该真正反映您的应用领域。它应该与您的域专家的观点相匹配。领域专家可以是您自己,您的客户或您雇佣的人,因为她是特定领域的专家(例如:会计,医疗保健,银行业务等)。在您的团队中拥有领域专家是应用DDD的要求。如果您的域名不够复杂,您将不再需要DDD。