领域模型

      领域模型是一种思维﹐是一种方法,是在系统分析阶段使用﹐而不是程序员在自己的代码中进行纯设计时的工具。我们不是为了OO而领域﹐不是为了最终要新增数据库而领域﹐这也是为什么在没有理解领域模型本质时﹐使用它进行片断式的代码编写﹐得不到任何好处的原因。

• 领域模型归业务代表所有。这就要从业务代表的头脑里抽象概念，并将这些概念嵌入到软件中，而不能从软件的角度思考，并试图影响业务代表。
• 技术团队是关键的利益相关者。我们将围绕具体细节据理力争。

覆盖领域模型的特定范围本身就很重要，因为它予以就任者处理项目中特定问题的真正工具。我们的领域模型中有几十个对象，所以我们只关注于高级别和更为明显的少数几个，在我们的情况中就是本文所讨论的各种内容和关键字概念。在这里我们做了三件事：

• 我们在白板上画出了概念及其关系，因此我们能给出系统如何工作的一个有形的表示。
• 我们确保每位编辑当场解释大量的领域模型，以强调领域模型不属于技术团队所有这一事实。
• 我们解释一些为了达到这一点而做出的历史变迁，所以就任者可以理解(a)这不是一成不变的，而是多变的，(b)为了进一步开发模型，他们可以在即将进行的对话中扮演什么样的角色。

 

在规划阶段利用DDD时我们使用的两个重要原则是：

1. 领域模型归属于业务；
2. 领域模型需要一个权威的业务源。

 

      技术团队的关键角色是聆听并理解，而不是解释什么可能、什么不可能。需求抽象要求将概念性的领域模型映射到具体的功能需求上，并在存在不匹配的地方对业务代表提出异议或进行询问。接着，存在不匹配的地方要么改变领域模型，要么在更高层次上解决功能需求（“你想用此功能达成什么效果？”）。

对领域模型来说，权威的业务源是我们组织的性质所明确需要的。
敏捷开发原则则可以：

• 构建最简单的东西。尽管我们无法在早期解决所有的细节，但通常能对构建下一个有用的功能有足够的理解。
• 频繁发布。通过发布此功能，我们能看到功能如何实际地运转。进一步的调整和进化步骤因此变得最为明显（不可避免，它们往往不是我们所预期的）。
• 降低变化的成本。利用这些不可避免的调整和进化步骤，减少变化的成本很有必要。对我们来说这包括自动化构建过程和自动化测试等。
• 经常重构。经过几个演进步骤，我们会看到技术债务累积，这需要予以解决。