我正在尝试基于现有的基于 C# WinForm 的系统对我的域进行建模，以提高我对 DDD 的学习，因此我整理了一个假设的概念模型来简化问题。系统本身没有一个典型的业务域，其中有很多逻辑混入到实体框架对象中，这些对象在系统的各个方面都被使用。我觉得这是一个大泥球（BBOM）。
我在工作中处理了一些 DDD 概念，但我想提高我的整体理解。我通读了 Evans 的蓝皮书“领域驱动设计：解决软件核心的复杂性”和 Scott Millets 的“领域驱动设计的模式、原则和实践”。以及观看有关该主题的无数视频，以及 Vaughn Vernon 的文章。我觉得这些年来我做了更多的数据驱动开发，这需要很长时间才能融入其中。
所以假设的系统是一个严格的质量控制系统，用于构建产品，它松散地遵循我所做的系统。
这是概念模型：
现在我看到了 3 个部分 - 不一定是有界上下文，但我正在努力确定这些有界上下文所在的位置。
业务流程分为3个部分：
- 定义产品
为此，“用户”将输入包括名称在内的各种产品信息。作为其中的一部分，他们定义了产品应该是什么厚度以及它是由什么材料制成的。他们还将定义构建器需要使用什么过程来构建产品。它们还定义了是否需要进行外观检查和质量检查。
- 构建产品
作为该过程的一部分，“建造者”将组装产品。但这仅限于建筑商的资格。Builder 符合基于厚度范围和材料的工艺的资格，因此业务规则仅允许选择 Builder，如果他们有资格获得介于工艺厚度范围和材料之间的产品厚度。
- 检查
产品构建完成后，即可对其进行检查。作为其中的一部分，根据是否需要外观检查或质量检查类型，最新合格的“检查员”将能够检查产品。他们将通过或不通过检查。
作为这些流程的一部分，产品的状态将被更新。这将是：
- 未组装
- 组装好的
- 部分检查（已完成两项检查之一）
- 通过检查（所有检查完成）
- 检查失败（任何检查失败）
以下是有关域外系统的一些信息，需要深思熟虑：
- 该系统被设计为一个多用户，可以同时输入检查
- 可能在产品上输入的数据不正确，可以更正，这可能会使任何输入的构建和检查数据无效
- 然后将输入的数据用于各种报告中。
所以我需要一些想法：
- 我的限界上下文在哪里。
如何为我的聚合根建模 - 哪些数据应该是根以及我应该包含哪些实体/值对象。
我是否只在有界上下文中包含我需要的域对象的数据 - 即不完全水合域对象。
如何通过流程的不同部分实现一些计算状态的东西。
- 如何处理数据输入错误的可能性以保持域数据正确。
我对任何存储库实现不感兴趣，只对纯领域概念感兴趣，尽管我们应该为每个有界上下文坚持什么的问题会对我有所帮助。
我担心有多个用户输入数据以保持产品状态的数据一致