《实现领域驱动设计》（美）弗农著 2章领域、子域、限界上下文

最新推荐文章于 2020-10-19 10:44:23 发布

Andy技术支援

最新推荐文章于 2020-10-19 10:44:23 发布

阅读量263

点赞数

分类专栏：读书笔记文章标签： java

本文链接：https://blog.csdn.net/zhuyufan1986/article/details/105492996

版权

读书笔记专栏收录该内容

36 篇文章 7 订阅

订阅专栏

领域（Domain)
即是一个组织所做的事情以及其中包含的一切。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。领域既可以表示整个业务系统，也可以表示其中的某个核心域或支撑子域。

工作中的子域和限界上下文
让我们先来看看一个非常简单的例子——一个零售商在线销售产品的例子。
零售商的领域可以分为个主要的子域：产品目录（product catalog)、订单(order)、发票(invoicing)、物流(shipping),再加入一个库存系统（inventory)
在这里插入图片描述
事实上，这些领域模型被融合成了一个软件模型。
子域并不是一定要做得很大，有时候，子域可以简单到只包含一套算法，这套算法可能对于业务系统来说非常重要，但是并不包含在核心域之中。

将关注点放在核心域上
领域的另一个抽象视图。
在这里插入图片描述核心域，它是整个业务领域的一部分，也是业务成功的主要促成因素。
支撑子域，有时候我们会创建或购买某个限界上下文来支撑我们的业务，对应着业务的某些重要方面，但不是核心。
通用子域，一个子域被用于整个业务系统。

战略设计为什么重要
saasovation公司项目进展情况，他们遇到麻烦了。
在这里插入图片描述
开发人员将协作模型与用户和权限完全柔和在一起了，如果系统对用户或权限的处理方式有所修改，这将导致对协作模型的修改。
将用户和权限分离到一个安全子域，最好的方式是将用户和权限放到支撑子域或者通用子域中，因为另外的核心域也可能会用到相似的功能。他们先前的做法还很有可能导致大泥球架构。

现实世界中领域和子域
问题空间是领域的一部分，是核心域和其他子域的组合，他们各自关注于当前的业务问题。
解决方案空间包括一个或多个限界上下文，即一组特定的软件模型。它是通过软件的方式来实现解决方案。

让我们来看看一个大型ERP系统，由于ERP系统可以提供许多模块化的业务服务，将不同的模块看成不同的子域是有好处的。我们将库存模块和采购模块拆分成不同的逻辑子域，分别为库存子域和采购子域。
在这里插入图片描述
理解限界上下文
限界上下文是一个显式的边界，领域模型存在于这个边界内，让我们来看看一个账户模型在银行上下文和文学上下文的不同。光凭名字我们无法区别两个账户的意思，只有限界上下文我们才能区别。
在这里插入图片描述如何解决图2.3中的建模问题。
moderator将使用对应用户的一部分熟悉，另外还需要一个角色名。
如果你在不同的限界上下文中看到了完全相同的对象，这意味着你的模型是错误的。除非这些限界上下文是用了共享内核。

限界上下文不仅仅只包含模型
一个限界上下文不只包含领域模型，它通常标定一个系统，一个应用或者一种业务服务。一个通用子域便可以只包含领域模型。
当设计数据库时，数据库也应该位于该模型所处的上下文边界之内，表名和列名应该和模型保持一致，比如backlogItem类，
在这里插入图片描述

如果用户界面被用于渲染模型，该用户界面也应该属于模型所在的上下文边界之内，但这并不表示我们应该在用户界面中对领域模型进行建模，这将导致贫血领域对象。
通常情况下系统中会存在其如web服务的组件，也可以使用Rest资源来与模型交互，那些面向服务的组件都应该位于上下文边界之内。
应用服务包含了不同类型的服务，比如安全和事务管理，同时还有任务管理，它将用例流的请求转化成领域逻辑的执行流，应用服务也应该位于上下文边界之内。

限界上下文大小
限界上下文应该包括模块、聚合、领域事件、领域服务等，限界上下文应该足够大，以能够表达它所对应的整套通用语言。
哪些因素会导致我们创建大小不正确的限界上下文？

软件架构；
开发任务来拆分限界上下文。

与技术组件保持一致
技术组件并不能定义限界上下文。在同一个解决方案中将用户界面、应用服务和领域对象分离在不同的子项目是合理的，项目源代码可以只包含领域模型。在java中顶层包名通常表示限界上下文中顶层模块的名字。
com.mycompany.optimalpurchasing
限界上下文的源代码结构可以根据架构进一步分解。
com.mycompany.optimalpurchasing.presentation
com.mycompany.optimalpurchasing.application
com.mycompany.optimalpurchasing.domain.model
com.mycompany.optimalpurchasing.infrastructure

示例上下文
在这里插入图片描述 协作上下文
我们选择性的讲解部分领域模型，即论坛和共享日历。
在实现代码中，他们在核心业务逻辑中去检查客户的权限：
以上代码展示了一种不好的设计，开发人员考虑的不是一个协作模型，而是一个与安全相关的模型。
在这里插入图片描述
以上代码移除了user和permission,并将关注点完全限制在协作活动上。