DDD在以下招聘系统中的应用

Question

我在应用DDD时遇到了问题大多数在线示例要么太复杂要么太简单( Item/ItemOrder类型)

我有一个招聘系统，A部门可能有多个专业(一个职业没有部门就不能存在)一个招聘渠道可能有多个招聘来源(一个招聘来源没有招聘渠道就不能存在)现在我有一个申请人没有专业就不能存在，没有招聘来源就不能存在。此外，如果没有候选人，面试也不能存在(然而，我在另一个有界的上下文中看到了面试部分，比如通过域事件传递的面试日历)

我正在尝试理解如何在DDD、AggregateRoot等方面提取什么(我相信我有两个竞争对手部门和招聘渠道)如果我选择一个而不是另一个，我如何处理另一个？

也许我做错了。如果有人能给我点启发，那将是非常有帮助的。

Answer 1

也许我做错了。如果有人能给我点启发，那将是非常有帮助的。

第一步:看看无处不在的语言。与您的领域专家坐下来，真正仔细地关注他们所谈论的实体。

例如：

没有职业就不能存在和没有招聘来源就不能存在的

申请者。

这看起来有点奇怪。我希望应聘者是个人，没有“招聘来源”(不管是什么)的人肯定是存在的。如果你说一个应用程序没有招聘来源就不能存在，或者更好的是申请总是由招聘来源推荐的，我更有可能相信你实际上是在与该领域的专家交谈。

域模型不描述结构；域模型控制变化。

在了解模型允许的更改之前，您无法做出有关聚合的智能设计决策。或者更确切地说，哪些更改是不允许的。

识别实体是建模工作的一部分，但您确实需要仔细注意哪些实体从属于模型。例如，考虑Customer vs Account；模型可能无法控制客户(您的模型能阻止人类更改他们的名字吗？或移动？)，但它可能能够控制帐户(暂停、跟踪促销优惠、提升到VIP状态)。

启发式:如果你的业务不能控制它，那么你的模型也不能控制它。

Answer 2

看起来，你没有ask right questions到你的领域专家。你在这里得到的所有信息都是可以/不能存在于其他东西中的。你知道what does系统中的专业、部门、面试的背景吗？

您的需求都是关于数据(表关系)的，而不是behaviour本身。

在DDD中，您将verbs放在名词之上。并将它们作为聚合方法进行捕获。然后，您可以根据事务边界来选择聚合边界(是否需要这样做，或者可以等待？)。

• 首先向您的领域专家咨询有关系统requirements的问题。它应该提供什么功能。
• 然后问起user stories，这只是系统的简单用法。但是don't talk about the front！这是not user story -当用户点击购买按钮并提交表单时，他购买了一个产品，这可能是您的user story -作为用户，当我购买汽车并且我是贵宾时，我应该获得20%的折扣，所以我将再次购买soon

您可以从用户故事中提取一些有用的信息，这些信息不仅仅是：“商店可以有多个产品，但产品可以有一个标题。”我希望你能得到一分。

关于如何对聚合建模，请看这里的Vaughn Vernon