领域驱动设计示例

我以前看过很多IT项目。有的设计得很好，有的设计得很差。基于这些经验，我想写一点关于一个示例项目的内容，我还想展示如何用UML对一个示例项目进行建模，以及如果我们将领域驱动的设计原则应用到模型中会发生什么。

在继续之前，您应该阅读Eric Evans的“域驱动设计”和Vaughn Vernon的“实现域驱动设计”两本书。这个例子大部分都是基于他们的工作，如果你想深入研究领域驱动的设计，他们的书是必读的。

需求

一家公司为其提供车身租赁服务。他们有一些雇员，也有很多自由职业者作为分包商。目前，他们使用Excel表格来管理客户、自由职业者、时间表等等。Excel解决方案的伸缩性不好。它不支持多用户，也不提供安全和审核日志。所以他们决定建立一个新的基于网络的解决方案。以下是核心要求：

• 必须提供可搜索的自由职业者目录
• 新的解决方案必须允许存储不同的通信渠道，以联系自由职业者
• 必须提供可搜索的项目目录
• 必须提供可搜索的客户目录
• 必须保留合同下自由职业者的时间表

基于这些需求，开发团队决定使用UML对所有内容进行建模，以获得新解决方案的总体情况。现在让我们看看他们做了什么。

大局

好的，这是他们第一次设计的：

这很直截了当。有客户，自由职业者，项目和时间表。还有一种用户管理来支持基于角色的安全性。但是等等，这里出了点问题。有一些隐藏得很好的设计缺陷。你能看见他们吗？它们在这里：

ContactType
freeloper

整个模型似乎更像是一种实体关系图，而不是一个软件模型。还有，业务逻辑是什么？团队希望围绕模型创建一些业务服务来存储和检索数据，实体只是由JPA管理的pojo。

一个贫血的领域模型。团队也承认这一点。但解决办法是什么呢？嗯，一位高级团队成员建议使用领域驱动的设计原则来建模解决方案。好的，现在让我们看看DDD如何改进设计。

DDD方式

在深入研究领域驱动设计之前，我们应该先谈谈DDD背后的原理。

DDD背后的一个原则是，通过使用相同的语言来创建相同的理解，从而弥合领域专家和开发人员之间的鸿沟。另一个原则是通过应用面向对象的设计和设计模式来减少复杂性，以避免重新发明轮子。

但什么是域名？领域是一个“知识领域”，例如公司经营的业务。一个领域也被称为“问题空间”，所以我们必须为这个问题设计一个解决方案。

好的，让我们看看要求。我们可以认为有一个“身体租赁”领域，这是完全正确的。但如果我们更深入地研究这个领域，我们会发现一些叫做“子域”的东西。可能有以下子域：

• 身份和访问管理子域
• 自由职业者管理子域
• 客户管理子域
• 项目管理子域

啊！我们可以把大问题分解成小问题。这可以帮助我们设计更好的解决方案。

分离的域可以很容易地可视化。在DDD术语中，这称为上下文映射，它是任何进一步建模的起点。

现在我们需要将子域问题空间与我们的解决方案设计对齐，我们需要形成一个解决方案空间。DDD术语中的解空间也称为有界上下文，最好将一个问题空间/子域与一个解空间/有界上下文对齐。

构建模块

领域驱动设计的构建块被划分为战术和战略模式 。

请注意，以下架构模式和类图与技术无关。这个解决方案可以使用JavaSE/EE、C#甚至JavaScript来实现。没关系，我们可以利用每一项目标技术实现同样的好处。

新的大局

好的，现在让