【发布时间】：2016-04-02 15:09:32
【问题描述】：
我正在尝试基于现有的基于 C# WinForm 的系统对我的域进行建模，以改进我对 DDD 的学习，因此我整理了一个假设的概念模型来简化问题。系统本身没有一个典型的业务领域，其中有很多逻辑混入到实体框架对象中，这些对象在系统的各个方面都被使用。我觉得这是一个大泥球（BBOM）。
我在工作中研究过一些 DDD 概念，但我想提高我的整体理解。我通读了 Evans 的蓝皮书“领域驱动设计：解决软件核心的复杂性”和 Scott Millets 的“领域驱动设计的模式、原则和实践”。以及观看无数关于该主题的视频，以及 Vaughn Vernon 的 articles。我觉得这些年来我做了更多的数据驱动开发，这需要很长时间才能融入其中。
所以假设的系统是一个严格的质量控制系统，用于构建产品，它松散地遵循我所做的系统。
这是概念模型：
现在我看到了 3 个部分 - 不一定是有界上下文，但我正在努力确定这些有界上下文所在的位置。
业务流程分为 3 个部分：
- 定义产品
为此，“用户”将输入包括名称在内的各种产品信息。作为其中的一部分，他们定义了产品应该是什么厚度以及它是由什么材料制成的。他们还将定义构建器需要使用什么过程来构建产品。他们还定义了是否需要进行外观检查和质量检查。
- 构建产品
作为流程的一部分，“制造商”将组装产品。但这仅限于建筑商的资格。 Builder 符合基于厚度范围和材料的工艺，因此业务规则仅允许选择符合产品厚度介于工艺厚度范围和材料之间的 Builder。
- 检查
产品构建完成后，即可进行检查。作为其中的一部分，根据是否需要外观检查或质量检查类型，最新的合格“检查员”将能够检查产品。他们将通过或不通过检查。
作为这些流程的一部分，产品的状态将会更新。这将是：
- 未组装
- 组装完毕
- 部分检查（已完成两项检查之一）
- 通过检查（所有检查已完成）
- 检查失败（任何检查失败）
以下是有关域外系统的一些需要深思熟虑的信息：
- 系统设计为多用户，可以同时输入检查
- 可能在产品上输入的数据不正确，可以更正，这可能会使任何输入的构建和检查数据无效
- 然后将输入的数据用于各种报告中。
所以我需要一些想法：
- 我的限界上下文在哪里。
-
如何为我的聚合根建模 - 哪些数据应该是根以及我应该包含哪些实体/值对象。
我是否只在有界上下文中包含我需要的域对象的数据 - 即不完全水合域对象。
如何通过流程的不同部分实现计算状态。
- 如何处理数据输入错误的可能性以保持域数据正确。
我对任何存储库实现都不感兴趣，只对纯领域概念感兴趣，尽管对于每个有界上下文我们应该坚持什么的问题会对我有所帮助。
我担心有多个用户输入数据以保持产品状态的数据一致
【问题讨论】：
-
这些是不同的问题。我认为您应该为他们提出单独的问题。
-
有界上下文/聚合设计通常是分析现实生活中的约束并与领域专家一起建模的结果。虚构的域很难使用，因为您没有这些强大的业务和技术限制来指导您。有了所有这些你没有现实世界事实可以决定的问号，你发现自己陷入分析瘫痪的风险很高。
-
同意。但是为了在这里保持一个简单的例子，我把这个概念和我认为足够详细的东西放在一起，希望能对从哪里开始有所了解。我对允许谁根据某些业务规则执行构建有限制。该数据被捕获并输入。域模型将阻止进入构建者不合格的构建。也许我确实投入了太多，但如果我可以改写这个问题，我会的 - 这将是在图表上将一些代码放在一起。我猜想识别有界上下文会出现。有什么想法吗？
标签： domain-driven-design aggregateroot bounded-contexts