领域驱动设计简介

? 模型与模型视图

所以模型是我们选择在软件中实现的概念集，以代码和用于构建交付系统的任何其他软件工件表示。换句话说，代码本身就是模型。文本编辑器提供了使用此模型的一种方法，尽管现代工具也提供了许多其他可视化效果（UML 类图，实体关系图，Spring beandocs [2]，Struts / JSF 流程等）。

这是 DDD 模式的第一个：模型驱动的设计。 这意味着能够将模型中的概念（理想情况下完全按字面意义）映射到设计/代码的概念。 模型的改变意味着代码的改变。 更改代码意味着模型已更改。 DDD 并不要求您使用面向对象对域进行建模-例如，我们可以使用规则引擎来构建模型-但鉴于主要的企业编程语言是基于 OO 的，因此大多数模型本质上都是 OO。 毕竟，OO 是基于建模范例的。 模型的概念将表示为类和接口，职责将表示为类成员。

沟通语言

现在让我们

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

看一下域驱动设计的另一个基本原理。回顾一下：我们想构建一个域模型来捕获正在构建的系统的问题域，并且我们将在代码/软件工件中表达这种理解。为了帮助我们做到这一点，DDD 提倡领域专家和开发人员使用模型中的概念有意识地进行交流。因此，域专家不会根据屏幕或菜单项上的字段来描述新的用户故事，而是谈论域对象所需的基础属性或行为。同样，开发人员也不会谈论数据库表中类或列的新实例变量。

严格执行此操作，我们将开发一种无处不在的语言。如果无法轻松表达一个想法，则表示领域模型中缺少一个概念，团队将共同努力找出该概念是什么。一旦建立了该概念，屏幕就会出现一个领域或数据库表的列上的新字段便会随之出现。

像大多数 DDD 一样，这种开发无处不在的语言的想法并不是一个真正的新想法：XPers 称其为“名称系统”，并且 DBA 多年来一直将数据字典放在一起。但是无处不在的语言是一个令人回味的术语，并且可以出售给商务和技术人员。现在，“整个团队”敏捷实践已成为主流，这也变得很有道理。

模型和上下文...

每当我们讨论模型时，它总是在一定范围内。通常可以从使用该系统的最终用户集合中推断出此上下文。因此，我们有一个部署到交易员的前台交易系统，或一个超市收银员使用的销售点系统。这些用户以特定的方式与模型的概念相关，并且模型的术语对这些用户有意义，但对于上下文之外的任何其他人则不一定。 DDD 将此称为有界上下文（BC）。每个域模型仅存在于一个有界上下文中，而有界上下文恰好包含一个域模型。

我必须承认，当我第一次了解有界上下文时，我看不出要点：如果 BC 与域模型同构，为什么要引入一个新术语？如果只有最终用户与 BC 进行交互，那么这个术语也许就不需要了。但是，不同的系统（BC）也彼此交互，发送文件，传递消息，调用 API 等。如果我们知道有两个 BC 相互交互，则我们必须注意在一个概念之间进行转换：域和其他域。

在模型周围放置明确的边界还意味着我们可以开始讨论这些 BC 之间的关系。实际上，DDD 标识了 BC 之间的一整套关系，以便我们可以合理化在需要将不同的 BC 链接在一起时应该采取的措施：

• 已发布的语言：交互的 BC 商定一种共同的语言（例如，企业服务总线上的一堆 XML 模式），通过它们它们可以彼此交互。

• 开放主机服务：BC 指定任何其他 BC 可以使用其服务的协议（例如 RESTful Web 服务）；

• 共享内核：两个 BC 使用通用的代码内核（例如，库）作为通用的通用语言，但否则以其自己的特定方式来完成其他工作；

• 客户/供应商：一个 BC 使用另一个服务的服务，并且是另一个 BC 的利益相关者（客户）。因此，它可以影响该 BC 提供的服务；

• 遵循者：一个 BC 使用另一个服务，但不是该另一个 BC 的利益相关者。因此，它使用“原样”（符合）该 BC 提供的协议或 API；

• 反腐败层：一个 BC 使用另一方的服务，而不是利益相关者，但其目的是通过引入一组适配器将一个 BC 依赖的 BC 的变化所产生的影响降至最低，即反腐败层。使用反腐败层，可以降低依赖风险，特别是在与旧系统集成时，至少实现反腐败层比重新实现该旧系统性价比要高很多。

DDD 建议我们绘制一个上下文图，以识别我们的 BC 和我们依赖或依赖的 BC，并确定这些依赖的性质。

所有有关上下文映射和 BC 的讨论有时都称为战略 DDD，这是有充分理由的。毕竟，考虑一下 BC 之间的关系是很政治的：我的系统将依赖于哪个上游系统，我是否容易与它们集成，我对它们有影响力，我信任它们吗？下游也是如此：哪些系统将使用我的服务，我如何将我的功能作为服务公开，它们对我有影响？一旦产生误解，应用程序很容易失败。

图层和六边形

现在，我们开始向内考虑我们自己的 BC（系统）的体系结构。从根本上讲，DDD 只真正关心域层。

当然，我们多年来一直在构建多层系统，但这并不意味着我们一定很擅长。确实，过去有一些主导技术-比如 EJB ，所有业务逻辑似乎都渗透到应用程序层甚至表示层中，留下一组数据实体类作为数据持有者，也就是所谓的贫血模型。这不是 DDD 的意思。

分层架构是一种历史悠久的架构，通过分层架构，可以将系统按不同职责组织成有序层次，由于这种划分往往比较容易界定，也算是最常见和最受欢迎的一种架构，有一个说法是：“如果你不知道要用什么架构，那就用它。

当我们说一个系统是分层架构的时候，你可以把这个软件想象成一个有很多层的蛋糕的样子，其中每一层放在它的下一层上。较高层使用诸多较低层定义和提供的服务，但较低层并没有察觉较高层的存在。另外，每一层都会对其上层隐藏更低的层。

分层体系结构的一个缺点是，它建议线性依赖关系的堆叠，从表示层一直到基础结构层。但是，我们可能希望在表示层和基础结构层中支持不同的实现。

因此，不是将我们的应用程序视为一组图层，而是将其视为六边形，如图所示。六边形的内部代表了 application 和 domain 层。外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以 API 呈现。