实践领域驱动设计-读书笔记

如何用好这本书

 

DDD 总览

 

早些时候，我讲到了 DD 的通用语言（Ubiquitous Language,1)。通用语言

 

作用于某个限界上下文（Bounded Context,2），它对于领域建模是非常重要的，你应该好好地熟悉一下。请记住，不管你是在战术上还是战略上设计软件模型，你都应该保证：在一个特定的限界上下文中只使用一套通用语言，并且保证它的清晰性和简洁性。

战略建模

限界上下文是一种概念上的边界，领域模型便工作于其中。同时，限界上下文为通用语言提供了一套环境，项目成员便通过通用语言来表达软件模型，如图 G.1

 

 

 

 

总览：

 

领域和界定上下文

 

什么是领域：

从广义上讲，领域（Domain）即是一个组织所做的事情以及其中所包含的切。商业机构通常会确定一个市场，然后在这个市场中销售产品和服务。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。当你为某个组织开发软件时，你面对的便是这个组织的领域。这个领域对于你来说应该是明晰的，因为你在这个领域中工作。

 

领域  1对多个 子域

子域 1对多个界定上下文

 

 

界定上下文=模型名+上下文

和你的业务领域模型相关，应该足够大到可以很准确的表达其所对应的整套通用语言！

所以，通用语言是限界上下文的重要输入和边界限定的主要依据。

具体落地，体现在顶层模块的名字。

com.xx.data.app.np.domain.*;

其中np就可以对应到一个限界上下文上。

 

 

上下文映射图续

系统间的集成常常依赖于RPC，网络和远程系统的加载过程都是RPC产生延迟的原因。当RPC的目标系统不可用时，系统也就不可能用了。一种方式是选择异步请求或者事件处理的方式。DDD主张在本地缓存由外部模型翻译而来的领域对象，这些对象保留这本地模型所需的最小状态集；然而，要与远程模型保持同步，最好的方式是在远程系统中采用面向消息的通知机制。

 

 

 

 

 

 

架构

 

 

 

六边形架构：端口与适配器，

是一种依赖倒置的场景实现，服务提供方为依赖它的consumer提供对应的实现（适配器）

 

面向服务架构

 

REST架构风格

资源是关键的概念

 

事件驱动架构

EDA：是一种处理事件生成、发现和处理等任务的软件架构。

类似于管道和过滤器：

cat phone_number.txt | grep 130 | wc -l

 

长时处理过程Saga

事件驱动的、分布式的并行处理模式—长时处理过程（long Running proces）

 

CQRS

CQRS（Command & Query Responsibility Segregation）命令查询职责分离，和 REST 同属于架构风格，如果单纯理解

实现领域驱动设计CQRS，是比较容易的，另一种方式解释就是，一个方法要么是执行某种动作的命令，要么是返回数据的查询，命令的体现是对系统状态的修改，而查询则不会，职责的分离更加有利于领域模型的提炼，系统的灵活性和可扩展性也得到进一步加强。

 

总结：六边形架构是DDD的首选架构方式，因为领域内聚，不需要关心外部的依赖。通过适配器去解决外部依赖。

 

 

 

 

值对象

 

当你决定一个领域概念是否是一个值对象时，你需要考虑它是否拥有以下特征

 

它度量或者描述了领域中的一件东西。

 

它可以作为不变量

 

它将不同的相关的属性组合成一个概念整体（Conceptual Whole）。

 

当度量和描述改变时，可以用另一个值对象予以替换。

 

它可以和其他值对象进行相等性比较。

 

它不会对协作对象造成副作用【Evans】。

 

java值对象：https://www.jdon.com/53373

一个实际case: 员工与地址，地址及可被设计成值对象，https://www.cnblogs.com/leo_wl/p/4122147.html

 

 

聚合