领域驱动设计简介(领域驱动设计)

作者:xinwang_m@163.com
发布时间: 2020-07-17 04:55:01 (5年前)
关键词: 领域驱动设计
摘要:

                              
                                     今天的企业应用程序无疑是复杂的，需要依靠一些专门技术（持久性，AJAX，Web服务等）来完成他们的工作。作为开发人员，我们倾向于关注这些技术细节，这是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没用，无论它看起来多么漂亮或者如何很好地构建其基础设施。

今天的企业应用程序无疑是复杂的，需要依靠一些专门技术（持久性，AJAX，Web服务等）来完成他们的工作。作为开发人员，我们倾向于关注这些技术细节，这是可以理解的。但事实是，一个不能解决业务需求的系统对任何人都没用，无论它看起来多么漂亮或者如何很好地构建其基础设施。
领域驱动设计（DDD）的理念- 首先由Eric Evans在他的同名书中描述 - 是关于将我们的注意力放在应用程序的核心，关注业务领域固有的复杂性本身。我们还将核心域（业务独有）与支持子域（通常是通用的，如钱或时间）区分开来，并将更多的设计工作放在核心上。
领域驱动设计包含一组用于从领域模型构建企业应用程序的模式。在您的软件生涯中，您可能已经遇到过许多这些想法，特别是如果您是OO语言的经验丰富的开发人员。但将它们一起应用将允许您构建真正满足业务需求的系统。
在本文中，我将介绍DDD的一些主要模式，了解一些新手似乎很难解决的问题，并突出显示一些工具和资源，以帮助您在工作中应用DDD。
代码和模型……
使用DDD，我们希望创建问题域的模型，持久性，用户界面和消息传递的东西可以在以后再创建，这是需要理解的业务领域，因为正在构建的系统中，可以区分公司的业务、核心竞争力以及竞争对手情况。（如果不是这样，那么考虑购买一个包装好的产品）。
根据模型，我们不是指一个或一组图表; 确实，图表很有用，但它们不是模型，只是模型的不同视图（参见图）。模型是我们选择在软件中实现的一组概念，用代码表示，以及用于构建交付系统的任何其他软件工件。换句话说，代码就是模型。文本编辑器提供了一种使用此模型的方法，尽管现代工具也提供了大量其他可视化（UML类图，实体关系图，Spring beandocs，Struts / JSF流等）。
<img src="/user/files/dfmtpKRdtugmYGL96YeIuMadcJq5MoRxyyDtiLE_oDo.png" alt="dfmtpKRdtugmYGL96YeIuMadcJq5MoRxyyDtiLE_oDo.png">
图1：模型与模型的视图
这是DDD模式中的第一个概念：模型驱动设计。这意味着能够将模型中的概念映射到设计/代码的概念（理想情况下），模型的变化意味着代码的变化; 更改代码意味着模型已更改。DDD并没有强制要求您使用面向对象来构建领域 - 例如，我们可以使用规则引擎构建模型 - 但是考虑到主要的企业编程语言是基于OO的，大多数模型本质上都是OO。毕竟，OO基于建模范例。模型的概念将表示为类和接口，作为类成员的职责。
谈谈语言
现在让我们看一下领域驱动设计的另一个基本原则。回顾一下：我们想要捕获一个问题域的域模型，并且我们将在代码/软件工件中表达成某种理解。为了帮助我们做到这一点，DDD提倡领域专家和开发人员有意识地使用模型中的概念进行沟通。因此，领域专家不会根据屏幕上的字段或菜单项来描述新的用户故事需求，而是讨论领域对象所需的基础属性或行为。类似地，开发人员不会讨论数据库表中的数据列以及新字段类型。
DDD严格要求我们开发出一种无处不在的语言。如果一个想法不能轻易地明确表达，那么它实际上在暗示背后有一个概念，这个概念在领域模型中缺失了，并且团队需要共同努力找出缺失的概念是什么。一旦建立了这个，那么数据库表中的屏幕或数据表列上的新字段等结果就自然产生。
像DDD一样，这种发现无处不在的语言的想法并不是一个新想法：XPers称之为“名称系统”，多年来DBA将数据字典放在一起。但无处不在的语言是一个令人回味的术语，可以出售给商业和技术人员。现在，“整个团队”敏捷实践正在成为主流，这也很有意义。
模型和上下文……
每当我们讨论模型时，它总是在某种情况下（某种背景条件下），通常可以从使用该系统的最终用户的使用情况来推断出这个上下文背景。比如，我们有一个部署到交易员前台的交易系统，或超市收银员使用的销售点系统，这些用户以特定方式与模型的概念相关，并且模型的术语对这些用户有意义，但不一定对该上下文之外的任何其他人有意义。DDD称之为有界上下文（BC）。每个域模型都只存在于一个BC中，BC只包含一个域模型。
我必须承认，当我第一次读到关于BC时，我看不出重点：如果BC与领域模型一样，为什么要引入一个新术语？如果只有最终用户与BC进行了互动，那么也许就不需要这个术语了。然而，不同的系统（BC）也相互交互，发送文件，传递消息，调用API等。如果我们知道有两个BC相互交互，那么我们知道我们必须注意进行概念之间进行转换：此域和其他域之间。
在模型周围设置明确的边界也意味着我们可以开始讨论这些BC之间的关系。实际上，DDD确定了BC之间的一整套关系，因此当我们需要将不同的BC链接在一起时，我们可以合理地确定应该做什么：
已发布的语言published language：交互式BC是就共同的语言（例如企业服务总线上的一堆XML模式）达成一致，通过它们可以相互交互; 开放主机服务open host service：BC指定任何其他BC可以使用其服务的协议（例如RESTful Web服务）; 共享内核shared kernel：两个BC使用一个共同的代码内核（例如一个库）作为一个共同的通用语言，但是否则以他们自己的特定方式执行其他的东西; 发布/订阅customer/supplier：一个BC使用另一个BC的服务，并且是另一个BC的利益相关者（客户端）。因此，它可以影响该BC提供的服务; 跟从者conformist：一个BC使用另一个BC的服务，但不是其他BC的利益相关者。因此，它使用“原样”（符合）BC提供的协议或API; 防腐败层anti-corruption layer：一个BC使用另一个服务而不是利益相关者，但旨在通过引入一组适配器 - 反腐败层来最小化BC所依赖的变化所带来的影响。 你可以看到，在这个列表中，两个BC之间的合作耦合水平是逐渐降低（见图2）。使用已发布的语言，我们从BC建立一个可以与之交互的共同标准，我们不拥有这种语言，而是拥有它们所在的企业（甚至可能是行业标准）。有了开放主机服务，我们仍然做得很好; BC提供其作为任何其他BC调用的运行时服务的功能，但随着服务的发展（可能）将保持向后兼容性。
<img src="/user/files/J5QySoBVYj5mStCdgURjK0NeGz2fjWWzt6P5A-zdBFw.png" alt="J5QySoBVYj5mStCdgURjK0NeGz2fjWWzt6P5A-zdBFw.png">
图2：有界上下文关系的谱
然而，当我们走向跟从模式时，我们只是一起调用和被调用; 一个BC明显屈服于另一个。如果我们必须与购买megabucks的总分类帐系统集成，那可能就是我们所处的情况。如果我们使用反腐败层， 那么我们通常会与遗留系统集成，但是额外的层将我们尽可能地隔离开来。当然，这需要花钱来实施，但它降低了依赖风险。反腐败层也比重新实现遗留系统便宜很多，这最多会分散我们对核心域的注意力，最坏的情况是以失败告终。
DDD建议我们制定一个BC图来识别我们的BC以及我们依赖或依赖的BC，以确定这些依赖关系的性质。图3显示了我过去5年左右一直在研究的系统的上下文映射。
<img src="/user/files/pwgSzSHC5rXVe2vXQpXQ7ezyArJiY9wmMfw4fauF1zI.png" alt="pwgSzSHC5rXVe2vXQpXQ7ezyArJiY9wmMfw4fauF1zI.png">
图3：上下文映射示例
所有这些关于有界上下文图和BC的讨论有时被称为战略性DDD，并且是有充分的理由的。毕竟，当你想到它时，弄清楚BC之间的关系是非常具有战略重要的：我的系统将依赖哪些上游系统，我是否容易与它们集成，我是否有利用它们，我相信它们吗？下游也是如此：哪些系统将使用我的服务，如何将我的功能作为服务公开，他们是否会对我有利？误解了这一点，您的应用程序可能很容易失败。
层和六边形
现在让我们转向内部并考虑我们自己的BC（系统）的架构。从根本上说，DDD只关心领域层，实际上它并没有很多关于其他层的说法：比如表现层，应用程序层或基础架构层（或持久层）。但它确实期望它们存在。这是分层架构模式（图4）。
<img src="/user/files/QJ-d6_JmLRxQD9gCKHQDYGcf5rk_LgIyUTdMbmbytqQ.png" alt="QJ-d6_JmLRxQD9gCKHQDYGcf5rk_LgIyUTdMbmbytqQ.png">
图4：分层架构
当然，我们多年来一直在构建多层系统，但这并不意味着我们必须擅长它。确实，过去的一些主流技术 - 例如EJB 2，对，我说的是它！ - 对领域模型可以作为有意义的层存在的想法产生了积极的影响。所有的业务逻辑似乎渗透到应用层或（更糟糕的）表现层，留下一组贫血的领域对象作为数据持有者的空壳(DTO或VO)，这不是DDD的意思。
因此，要绝对清楚，应用程序层中不应存在任何领域逻辑。相反，应用程序层负责事务管理和安全性等事务。在某些架构中，它还可能负责确保从基础结构/持久层中检索的领域对象在与之交互之前已正确初始化（尽管我更喜欢基础结构层执行此操作）。
如果表现层有单独的存储空间中（比如手机终端），应用层也充当表现层和领域层之间的中介。表现层通常处理领域对象或其他对象（数据传输对象或DTO）的可序列化表示，通常每个“视图”一个。如果这些被修改，则表示层将对应用程序层的任何更改发送回去，而应用程序层确定已修改的领域对象，并从持久层加载它们，然后转发对这些领域对象的更改。
分层架构的一个缺点是：它从表现层一直到基础结构层的依赖性是线性的。但是，我们可能希望在表现层和基础结构层中支持不同的实现。如果我们想测试我们的应用程序肯定是这样的：
例如，FitNesse等工具允许我们从最终用户的角度验证我们系统的行为。但是这些工具通常不会通过表示层，而是直接返回到下一层，即应用层。所以从某种意义上说，FitNesse就是另一种观察者。 同样，我们可能有多个持久性实现。我们的生产实现可能使用RDBMS或类似技术，但是对于测试和原型设计，我们可能有一个轻量级实现（甚至可能在内存中），因此我们可以模拟持久性。 我们可能还想区分“内部”和“外部”层之间的交互，其中内部我指的是两个层完全在我们的系统（或BC）内的交互，而外部交互跨越BC。
因此，不要将我们的应用程序视为一组图层，另一种方法是将其视为六边形，如图5所示。我们的最终用户使用的是查看器以及FitNesse测试使用内部客户端API（或端口），而来自其他BC的调用（例如，RESTful用于开放主机交互，或来自ESB适配器的调用用于已发布的语言交互）命中外部客户端端口。对于后端基础架构层，我们可以看到用于替代对象存储实现的持久性端口，此外，领域层中的对象可以通过外部服务端口调用其他BC。
<img src="/user/files/cSwmO05xkbiqzifsbS8-xRYxts4f_dai8o73aDf3I9o.png" alt="cSwmO05xkbiqzifsbS8-xRYxts4f_dai8o73aDf3I9o.png">
图5：六边形结构

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论