处理不断增长的域模型

Question

请允许我大胆地问(从业余的角度来看)，处理可能不断扩展的领域模型的一般策略是什么？

举个例子，我有Staff，一开始他们可以有一个部门(但遗憾的是，事实上，它必须是一个List<Department>，因为它从来没有那么容易，对吗？)然后我们去做一个停车场模块，每个工作人员都可以有一个List<Car>。好吧没什么大不了的。

然后介绍一种工作流模式。最后，我可能会有一名工作人员需要处理的一系列项目。所以我给员工List<WorkflowItem>添加了一个列表？(我是在正确的轨道上，还是已经出了什么问题？这感觉已经很奇怪了，但是从数据库的角度来看，这是有意义的--为John获得所有优秀的项目)

然后，我们讨论的是一个家长之夜的预订系统，学生们应该在那里和一名工作人员一起预订一个时段。现在我开始担心了。我的staff是否真的有一组时隙(可能在事件集合中)？可能不对？

似乎有道理的是，一个工作人员应该有他们的汽车，但不是他们的预订。这是一个合理的焦虑点，还是我遗漏了一些显而易见的东西？

重点是，我想我可以添加它，但是我们应该继续无限地添加属性吗？

Answer 1

你当然可以按照你的建议来设计这个模型，但是你最终会有一个(非常)大的泥球。您不是第一个遇到这个问题的人，这就是SOA、microservices和DDD等概念出现的原因。

其思想是，应用程序的关注点可以以相对独立的方式(服务)分组。例如，工作人员属于一个或多个部门，拥有一辆汽车，并有一个工作流项列表，这并不意味着您需要在一个地方使用这些概念来执行所需的逻辑。

停车场模块是否需要了解员工部门的情况？以及他们的工作流程项目？可能不会。那车的清单呢？可能是的。因此，您的停车场模块，可能有一个工作人员的名单，他们的汽车，但不是他们的工作流程项目。

请注意，另一个服务也可能有一个具有其他属性的工作人员列表。这些实际上不是重复的数据，因为它们基本上共享工作人员Ids，但不共享实际数据，仅仅是因为服务使用的数据与其他服务无关。

如果您遵循这种方法，您将看到在您的应用程序中没有一个“员工”实体。每一处都有“一部分”工作人员，这是在这方面相关的整体预测。在DDD中，几个有界上下文可能包含相同的概念，如"order“或"customer"，但含义不同。

这种方法带来了一些复杂性。例如，最终的一致性。在这个设置中，一个服务将负责创建(雇用？)删除(终止合同)的工作人员。当发生这种情况时，该服务将发布像StaffMemberHired或StaffMemberContractTerminated这样的事件。其他服务部门将听取这些事件并采取相应行动。例如，停车场服务将在停车场工作人员列表中创建一个条目。从现在起，该模块将允许用户为该新工作人员分配一辆汽车和一个停车位。当停车场模块接收到StaffMemberContractTerminated事件时，它将取消对她的停车位的分配，并将工作人员的进入标记为终止，这样就不可能再为其分配停车位了。最终一致性部分意味着有一种可能性，即在一段短时间内产生一名工作人员，而该工作人员仍然无法分配停车位，或该停车位已终止，但停车位仍然保留。这些情况通常在很短的时间内得到解决。

这些概念在一开始就有点混乱，有时也有点难以应用，但它们解决了您的问题:它们允许不断增长的域，因为您基本上向系统中添加了新的服务，而不是增加单个模型的大小。