我在应用DDD时遇到问题大多数在线发现的例子太复杂或太简单（Item / ItemOrder类型）
我有一个招聘系统， 部门可能有许多专业（没有部门就不能存在专业） 招聘渠道可能有多个招聘来源（如果没有招聘渠道，招聘渠道就不可能存在） 现在我有一个没有专业就不能存在的申请人，没有招聘来源就不能存在。 如果没有候选人，面试也不可能存在（但是我看到面试部分在另一个有限的上下文中，如通过domainevents发送的面试日历）
我试图了解如何提取DDD AggregateRoot等方面的内容（这里我相信我有两个竞争对手部门和招聘渠道） 鉴于我选择了一个而不是另一个，我将如何处理另一个？
也许我会以错误的方式去做。如果有人能照亮我，那将非常有帮助。
答案 0 :(得分：4)
也许我会以错误的方式去做。如果有人能照亮我，那将非常有帮助。
步骤1：看看无处不在的语言。与您的领域专家坐下来，并特别注意他们谈论的实体。
例如：
没有专业就不能存在的申请人，没有招聘来源就不能存在。
这看起来有点奇怪。我希望申请人成为一个人，而人们当然没有“招聘来源”（无论是什么）。如果您说如果没有招聘来源就无法存在应用程序，或者更好的是应用程序总是被招聘来源引用，我更有可能相信您实际上是在与域中的专家交谈。
域模型不描述结构;域模型控制变更。
在了解模型允许的更改之前，您无法对聚合做出明智的设计决策。或者更好地说，哪些变化都是 不允许。
识别实体是建模工作的一部分，但您确实需要特别注意哪些实体从属于模型。例如，考虑客户与账户;该模型可能无法控制客户（您的模型是否可以阻止人们更改姓名？或移动？），但它可能能够控制帐户（暂停，跟踪促销优惠，促进VIP状态）。< / p>
启发式：如果您的企业无法控制它，那么您的模型也无法控制它。
答案 1 :(得分：2)
似乎，你不是ask right questions给你的领域专家。
您在这里获得的所有信息都是可以/不能与其他东西存在的信息。
您是否了解what does职业，部门，系统背景下的面试？
您的要求都是关于数据（表关系），而不是behaviour本身。
在DDD中，您将verbs放在名词上。然后你将它们作为聚合方法捕获它们。然后根据事务边界选择聚合边界（是否需要发生这种情况，还是等待？）。
requirements的信息。它应该提供什么功能。user stories，这只是系统的简单用法。但是don't talk about the front！
这是not user story - 当用户点击购买按钮并提交表单时，他会购买产品
这可能是您的user story - 作为用户，当我购买汽车而且我是VIP时，我应该获得20％的折扣，因此我将很快再次购买 从用户故事中，您可以提取一些有用的信息，这些信息不仅仅是例如：＆＃34;商店可以有多个产品，但产品可以有一个标题。＆＃34; 我希望你明白我的意思。
关于如何为聚合建模，请查看Vaughn Vernon