具有聚合根的域模型的DDD概念模型

Question

我正在尝试基于现有的基于C＃WinForm的系统对我的域进行建模，以改善我对DDD的学习，因此我将一个假设的概念模型放在一起以简化问题。系统本身没有典型的业务域，其中有许多逻辑混合到Entity Framework对象中，这些对象通过系统的所有方面使用。我觉得这是一个大球泥（BBOM）。

我在工作中解决了一些DDD概念，但我希望提高我的整体理解。我读了埃文斯的蓝皮书“领域驱动设计：解决软件中心的复杂性”和Scott Millets“领域驱动设计的模式，原理和实践”。除了观看关于这个主题的无数视频，还有Vaughn Vernon的articles。多年来，我觉得已经做了更多的数据驱动开发，因此需要花费一个时间来吸收它。

因此，假设系统是一个严格的质量控制系统，用于构建产品，这些系统松散地遵循我所做的系统。

这是概念模型：

现在我看到3部分 - 不一定是有限的背景，但我正在努力确定这些有限的背景所在。

业务流程有3个部分：

1. 定义产品

为此，“用户”将输入包括名称在内的各种产品信息。作为其中的一部分，他们定义了产品应该具有的厚度以及它由何种材料制成。他们还将定义Builder需要使用哪些流程来构建产品。他们还定义是否需要目视检查和质量检验。

1. 构建产品

作为流程的一部分，“构建者”将组装产品。但这仅限于建筑商的资格。构建器符合基于厚度范围和材料的过程的要求，因此业务规则只允许选择构建器，如果它们符合过程厚度范围和材料之间的产品厚度。

1. 检验

产品构建完成后，可以进行检查。作为其中的一部分，根据是否需要视觉或质量检验类型，最新的合格“检验员”将能够检查产品。他们将通过或未通过检查。

作为流程的一部分，将更新产品的状态。这将是：

• 未装配
• 组装
• 部分检查（两次检查中的一次已经完成）
• 通过检查（所有检查完成）
• 检查失败（任何检查失败）

以下是关于域外系统的一些信息，需要一些思考：

• 系统设计为多用户，可以同时输入检查
• 可能在产品上输入的数据不正确，可以更正这些数据，这可能导致任何输入的构建和检验数据无效
• 然后，输入的数据将用于各种报告中。

所以我需要一些想法：

1. 我的有界背景所在。

2. 如何对我的聚合根进行建模 - 哪些数据应该是根，哪些实体/值对象应该包含在内。

   我是否只在有界上下文中包含我需要的域对象的数据 - 即不要完全保留域对象。

3. 如何通过流程的不同部分实现某些内容来计算状态。

4. 如何处理错误输入数据以保持域数据正确的可能性。

我对任何存储库实现都不感兴趣，只是对纯域概念感兴趣，尽管我们应该为每个有界上下文保留的内容对我有所帮助。

我的担忧是让多个用户输入数据以保持数据在产品状态

周围保持一致

Answer 1

您应该考虑的一件事是忽略DDD，直到您有一个有用的初始工作域模型，特别是当您的域很小时。忘记聚合和有界的上下文。像许多人一样，您将DDD的这些“构建块”视为工作应用程序的“基本部分”。它们不是......你的领域模型是。

请注意，默认情况下，您不需要有有界的上下文，聚合，域事件，服务，存储库或工厂。这些都是仅在必要的地方应用的概念。

您知道如何将域模型转换为工作应用程序吗？如果我能提供帮助，请告诉我。