JavaEdge全是干货的技术号

理解DDD就要理解通用语言和模型驱动设计。通用语言就是要把业务人员和开发人员对具体业务概念和逻辑的理解达成一致，可使用事件风暴和彩色建模等方法建立通用语言模型驱动设计可以从战略设计和战术设计两方面入手，战略设计属于高层设计，将系统安装领域拆分；战术设计属于低层设计，考虑的是如何组合业务模型建立一套业务人员和开发人员共享的通用语言。

IaaS主要是运维负责。ebay中台架构staffjoy 中台参考https://www2.slideshare.net/tcng3716/ebay-architecture

领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。 当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务。有时我们倾向于使用聚合根上的静态方法来实现这些这些操作，但是在 DDD中,这是一种坏味道本文目标如何在领域模型中使用领域服务什么是领域服务何时应该使用领域服务从案例学习如何对领域服务进行建模早期项目成员们在Product中维护了一个Backlogitem实例的集合。这种建模方式使得他们可以计算一个Produc的总业务优先级：当时这种设计方式非常完美，bus

如何将领域事件建模成对象，何时应该为领域事件创建唯一的身份标识?哪些组件用于发布事件，哪些组件用于订阅事件为什么我们需要一个事件存储?如何实现事件存储、如何使用事件存储?如何通过不同的方式将领域事件发布给自治系统1 when and why使用领域事件？1.1 定义使用领域事件时，首先就是要对不同事件进行定义。《领域驱动设计》并未给出领域事件的定义，因为该模型是在该书出版后才被提出。当前对领域事件的定义：领域专家所关心的发生在领域中的一些事件。将领域中所发生的活动建模成一系列的离散事件。.

支撑 DDD 最核心的就是通用语言和模型驱动设计的方法。本文专注模型的设计。模型设计，DDD 分两阶段，战略设计和战术设计。战略设计战略设计包含很多的概念：子域、限界上下文和上下文映射图等。这些概念分为：业务划分为了区分不同业务，也就是要将识别出来的业务概念做一个划分，落地成解决方案将划分出来的业务落实到真实的解决方案业务概念的划分软件开发就是解决问题，所以关键是：问题是什么如何解决我们要解决的问题就是领域问题，相关概念如，子域、核心域、支撑域、通用域等。其实都是：如何分解

现实的业务，非常复杂。即使同一事物，在多个业务下意义可能完全不同。比如【商品】：在商品详情页语境指【商品基本信息】在下单页语境指【购买项】在物流页面语境又是【被运送的货物】DDD 核心思想就是让正确的领域模型发挥作用。DDD 指导开发将不同子业务单元划分为不同子领域，在各个子领域内部分别建模应对业务的复杂性。1 背景经典的MVC开发，因为初期业务也比较简单，为光速上线， 综合考虑成本和风险，经常创建一个大模型，各个模块都想着直接复用这同一模型。但随业务发展，各子领域的逻辑越来越复杂，对该大模

值对象《实现领域驱动设计》对值对象的定义：通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。DDD中描述领域的特定方面，并且是一个没有标识符的对象。也就说，值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体。当度量和描述改变时，可以用另外一个值对象予以替换。它可以和其它值对象进行相等性比较，且不会对协作对象造成副作用。简单来说，值对象本质上就是一个集。那这个集合里面有什么呢？若干个用于描述目的、具有整体概念和不可修改的属性。那这个集合存在的意义又是

将实体（Entity）和值对象（ValueObject）组成聚合(Aggregate)，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。注意思考：聚合只是将一些共享父类、密切关联的对象聚集成一个对象树吗？如果是这样，对于存在于这个树中的对象有没有一个实用的数目限制？既然一个聚合可以引用另一个聚合，我们是否可以深度地递归遍 历下去，并且在此过程中修改对象呢？聚合的不变条件和一致性边界究竟是什么意思？聚合实体一般对应业务对象，具有

项目基本信息项目的目标是实现在线请假和考勤管理。功能描述如下：请假人填写请假单提交审批，根据请假人身份、请假类型和请假天数进行校验，根据审批规则逐级递交上级审批，逐级核批通过则完成审批，否则审批不通过退回申请人。根据考勤规则，核销请假数据后，对考勤数据进行校验，输出考勤统计。战略设计战略设计是根据用户旅程分析，找出领域对象和聚合根，对实体和值对象进行聚类组成聚合，划分限界上下文，建立领域模型的过程。战略设计采用的方法是事件风暴，包括：产品愿景、场景分析、领域建模和微服务拆分等几个主要过程。战略

1 服务协作1.1 服务的类型按照分层架构设计出来的微服务，其内部各层服务主要功能和职责如下：Facade服务位于用户接口层，包括接口和实现两部分。用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将数据传递给应用层。或者在获取到应用层数据后，将DO组装成DTO，将数据传输到前端应用。应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果拼装，对外提供粗粒度的服务。领域服务位于领域层。领域服务封装核心的业务逻辑，实现需要多个

实体和值对象都是领域模型中的领域对象。实体拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体。实体的业务形态DDD不同设计过程中，实体的形态不同。在战略设计时，实体是领域模型的一个重要对象。领域模型中的实体是多个属性、操作或行为的载体。在事件风暴中，我们可以根据命令、操作或者事件，找出产生这些行为的业务实体对象，进而按照一定的业务规则将依存度高和业务关联紧密的

微服务的设计要涉及到逻辑边界、物理边界和代码边界等。演进式架构很多人认为：“将单体拆分成多少个微服务，是微服务的设计重点。”真的吗？并非如此！Martin Fowler 在提出微服务时，他提到了微服务的一个重要特征——演进式架构。那什么是演进式架构呢？就是以支持增量的、非破坏的变更作为第一原则，同时支持在应用程序结构层面的多维度变化。如何判断微服务设计是否合理只需看是否满足这样的情形：随着业务的发展或需求的变更，在不断重新拆分或者组合成新的微服务的过程中，不会大幅增加软件开发和维护的成本，

将领域对象映射到微服务代码模型中。DDD强调先构建领域模型然后设计微服务以保证领域模型和微服务的一体性。但在构建领域模型时，我们往往是在业务视角，并且有些领域对象还带业务语言。我们还需要将领域模型作为微服务设计的输入，对领域对象进行设计和转换，让领域对象与代码对象建立映射关系。领域对象的整理完成微服务拆分后，领域模型的边界和领域对象就基本确定了。第一个工作就是，整理事件风暴过程中产生的各个领域对象，比如：聚合、实体、命令和领域事件，将这些领域对象和业务行为记录到下面表格。这张表格包含：领

微服务的设计和落地。微服务落地时首先要确定的就是微服务的代码结构。只有建立标准微服务代码模型和代码规范，才可以将领域对象所对应代码对象放在合适的软件包的目录结构中。统一标准的代码模型的好处：项目团队成员更好地理解代码，根据代码规范实现团队协作微服务各层的逻辑互不干扰、分工协作、各据其位、各司其职，避免不必要的代码混淆微服务架构演进时，轻松重构DDD分层架构与微服务代码模型参考DDD分层架构模型来设计微服务代码模型。没错！微服务代码模型就是依据DDD分层架构模型设计出来的。那为什么是DDD

通用语言定义上下文含义，限界上下文则定义领域边界，以确保每个上下文含义在它特定的边界内都具有唯一的含义，领域模型则存在于这个边界之内。你是不是感觉这么描述很抽象？没关系，接下来我会给你一一详细讲解。在这之前，我想请你先看这样两个问题，这也是今天内容的核心。1. 为什么要提出限界上下文的概念（也就是说除了解决交流障碍这个广义的原因，还有更具体的吗）？2. 限界上下文在微服务设计中的作用和意义是什么？什么是通用语言？什么是通用语言？为了更好地理解限界上下文，回答这两个问题，我们先从通用语言讲起。怎么理解通用语言

微服务架构模型有多种：整洁架构、CQRS、六边形架构等，核心理念都是“高内聚低耦合”。而DDD分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有重要地位。DDD分层架构传统四层架构将领域模型和业务逻辑分离出来，并减少对基础设施、用户界面甚至应用层逻辑的依赖，因为它们不属业务逻辑。将一个夏杂的系统分为不同的层，每层都应该具有良好的内聚性，并且只依赖于比其自身更低的层。传统四层架构中，基础层被其它层依赖，理论上它就是核心，但实际上领域层才是软件核心，所以这种依赖有问题。后来采用依赖倒

一些名词在你的微服务设计和开发过程中不一定都用得上，但它可以帮你理解DDD的核心设计思想和理念。而这些思想和理念，在IT战略设计、业务建模和微服务设计中都是可以借鉴的。让我们来理清它们与微服务的关系，了解它们在微服务设计中的作用。领域和子域领域用于确定边界，这也是为何DDD在设计中不断强调边界。DDD会按规则细分业务领域，细分到一定程度后，DDD会将问题范围限定在特定边界内，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。领域就是该边界内要解决的业务问题域。领域也有大小之分，其

贫血模型即是事务脚本模式，充血模型即是领域模型模式。贫血模型最早广泛应用是源自于EJB2，最强盛时期则是由Spring创造，把“行为”（也称为逻辑、过程）和“状态”（可理解为数据，对应到语言就是对象成员变量）分离到不同的对象之中，那个只有状态的对象就是所谓的“贫血对象”（常称为VO——Value Object），而那个只有行为的对象就是我们常见的N层结构中的Logic/Service/Manager层（对应到EJB2中的Stateless Session Bean）。（曾经Spring的作者Rod Jo