DDD

领域驱动设计 (Domain-Driven Design，简称 DDD）

2003 年的时候，Eric Evans 在2003年出版的: Domain-driven Design: Tackling Complexity in the Heart of Software， 正式定义了领域的概念，开始了 DDD 的时代。

Domain-Driven Design: Tackling Complexity in the Heart of Software 1st Edition Publisher: Addison-Wesley Professional; 1st edition (August 20, 2003)

2013 年，Vaughn Vernon 写了一本 Implementing Domain-Driven Design 进一步定义了 DDD 的领域方向，并且给出了很多落地指导，它让人们离 DDD 又进了一步。

什么是 DDD

  • 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反映了我们在领域内所关注的部分；
  • 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等； 还能反映领域中的一些过程概念，如资金转账，等；
  • 领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好地帮助；
  • 领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；
  • 领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息； 因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；
  • 要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；
  • 为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；
  • 领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速地响应需求变化；

DDD首先从业务领域入手，划分 业务领域边界，采用事件风暴工作坊方法，分析并提取业务场景中的实体、值对象、聚合根、聚合、领域事件等领域对象，根据限界上下文边界构建领域模型，将领域模型作为微服务设计的输入，进而完成微服务洋细设计。

用DDD方法设计出来的微服务，业务和应用边界非常清晰，符合“高内聚，低耦合”的设计原则，可以轻松适应业务模型变化和微服务架构演进。

——《基于DDD和微服务的中台架构与实现》 ———————————————— 版权声明：本文为 CSDN 博主「40岁资深老架构师尼恩」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/crazymakercircle/article/details/134128426

Martin Fowler在《企业应用架构模式》一书中写道:

I found this(business logic) a curious term because there are few things that are less logical than business logic.

初略翻译过来可以理解为: 业务逻辑是很没有逻辑的逻辑。 很多时候软件的业务逻辑是无法通过推理而得到的，有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时，除了应付业务上的复杂性，技术上的复杂性也不能忽略，比如我们要讲究技术上的分层，要遵循软件开发的基本原则，又比如要考虑到性能和安全等等。
DDD分为战略设计和战术设计。在战略设计中，我们讲求的是子域和限界上下文(Bounded Context,BC)的划分，以及各个限界上下文之间的上下游关系。当前如此火热的"在微服务中使用DDD"这个命题，究其最初的逻辑无外乎是"DDD中的限界上下文可以用于指导微服务中的服务划分”。事实上，限界上下文依然是软件模块化的一种体现，与我们一直以来追求的模块化原则的驱动力是相同的，即通过一定的手段使软件系统在人的大脑中更加有条理地呈现，让作为"目的"的人能够更简单地了解进而掌控软件系统。

如果说战略设计更偏向于软件架构，那么战术设计便更偏向于编码实现。DDD 战术设计的目的是使得业务能够从技术中分离并突显出来，让代码直接表达业务的本身，其中包含了聚合根、应用服务、资源库、工厂等概念。虽然 DDD 不一定通过面向对象(OO)来实现，但是通常情况下在实践 DDD 时我们采用的是 O O编程范式，行业中甚至有种说法是"DDD是OO进阶”，意思是面向对象中的基本原则(比如SOLID)在DDD中依然成立。

实现业务的3种常见方式

  1. 基于"Service + 贫血模型"的实现
  2. 基于事务脚本的实现
  3. 基于业务的分包

领域通用语言（UBIQUITOUS LANGUAGE）

我们认识到由软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的，但是，那种方法通常会由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式、架构，等等，总是想将实际生活中的概念和程序工件进行对应。他们希望看到要建立哪些对象类，要如何对对象类之间的关系建模。他们会习惯按照封装、继承、多态等面向对象编程中的概念去思考，会随时随地这样交谈，这对他们来说这太正常不过了，开发人员就是开发人员。但是领域专家通常对这一无所知，他们对软件类库、框架、持久化甚至数据库没有什么概念。他们只了解他们特有的领域专业技能。比如，在空中交通监控样例中，领域专家知道飞机、路线、海拔、经度、纬度，知道飞机偏离了正常路线，知道飞机的发射。他们用他们自己的术语讨论这些事情，有时这对于外行来说很难直接理解。如果一个人说了什么事情，其他的人不能理解，或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功呢？

在交流的过程中，需要做翻译才能让其他的人理解这些概念。开发人员可能会努力使用外行人的语言来解析一些设计模式，但这并一定都能成功奏效。领域专家也可能会创建一种新的行话以努力表达他们的这些想法。在这个痛苦的交流过程中，这种类型的翻译并不能对知识的构建过程产生帮助。

领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。使用模型作为语言的核心骨架，要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的，这种语言被称为“通用语言（Ubiquitous Language）”。通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通，从而发现要在模型中使用的主要的领域概念。

聚合, Aggregate

聚合根

一个基本原则：应尽量避免在聚合中使用资源库。

聚合根 (Aggregate Root, AR) 就是软件模型中那些最重要的以名词形式存在的领域对象， 比如本文示例项目中的 Order 和 Product。又比如， 对于一个会员管理系统，会员 (Member) 便是一个聚合根； 对于报销系统，报销单 (Expense) 便是一个聚合根； 对于保险系统，保单 (Policy) 便是一个聚合根。聚合根是主要的业务逻辑载体，DDD 中所有的战术实现都围绕着聚合根展开。

在本例中，Order 中的品项 (orderItems) 和总价 (totalPrice) 是密切相关的，orderItems 的变化会直接导致 totalPrice 的变化，因此，这二者自然应该内聚在 Order 下。 此外，totalPrice的变化是orderItems变化的必然结果，这种因果关系是业务驱动出来的，为了保证这种"必然”，我们需要在Order.changeProductCount()方法中同时实现"因"和"果”，也即聚合根应该保证业务上的一致性。在DDD中，业务上的一致性被称为不变条件(Invariants)。

对聚合根的设计需要提防上帝对象 (God Object)，也即用一个大而全的领域对象来实现所有的业务功能。 上帝对象的背后存在着一种表面上看似合理的逻辑: 既然要内聚，那么让我们把所有相关的东西都聚到一起吧，比如用一个Product类来应付所有的业务场景，包括订单、物流、发票等等。这种机械的方式看似内聚，实则恰恰是内聚性的反面。要解决这样的问题依然需要求助于限界上下文，不同限界上下文使用各自的通用语言(Ubiquitous Language)，通用语言要求一个业务概念不应该有二义性，在这样的原则下，不同的限界上下文可能都有自己的Product类，虽然名字相同，却体现着不同的业务。

聚合根的实现应该与框架无关: 既然 DDD 讲求业务复杂度和技术复杂度的分离，那么作为业务主要载体的聚合根应该尽量少地引用技术框架级别的设施，最好是POJO。试想一下，如果你的项目哪天需要从Spring迁移到Play，而你可以自信地给老板说，直接将核心Java代码拷贝过去即可，这将是一种多么美妙的体验。又或者说，很多时候技术框架会有"大步"的升级，这种升级会导致框架中API的变化并且不再支持向后兼容，此时如果我们的领域模与框架无关，那么便可做到在框架升级的过程中幸免于难。

聚合根之间的引用通过 ID 完成: 在聚合根边界设计合理的情况下，一次业务用例只会更新一个聚合根，此时你在该聚合根中去引用另外聚合根的整体有什么好处呢？在本文示例中，一个Order下的OrderItem引用了ProductId，而不是整个Product。 聚合根内部的所有变更都必须通过聚合根完成: 为了保证聚合根的一致性，同时避免聚合根内部逻辑向外泄露，客户方只能将整个聚合根作为统一调用入口。 如果一个事务需要更新多个聚合根，首先思考一下自己的聚合根边界处理是否出了问题，因为在设计合理的情况下通常不会出现一个事务更新多个聚合根的场景。如果这种情况的确是业务所需，那么考虑引入消息机制和事件驱动架构，保证一个事务只更新一个聚合根，然后通过消息机制异步更新其他聚合根。

聚合根不应该引用基础设施。 外界不应该持有聚合根内部的数据结构。 尽量使用小聚合。

如何创建好的聚合？

边界内的内容具有一致性：在一个事务中只修改一个聚合实例。如果你发现边界内很难接受强一致，不管是出于性能或产品需求的考虑，应该考虑剥离出独立的聚合，采用最终一致的方式。 设计小聚合：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。 通过唯一标识来引用其他聚合或实体：当存在对象之间的关联时，建议引用其唯一标识而非引用其整体对象。如果是外部上下文中的实体，引用其唯一标识或将需要的属性构造值对象。 如果聚合创建复杂，推荐使用工厂方法来屏蔽内部复杂的创建逻辑。

实体 vs 值对象 软件模型中存在实体对象(Entity)和值对象(Value Object)之说，这种划分方式事实上并不是DDD的专属，但是在DDD中我们非常强调这两者之间的区别。

实体对象表示的是具有一定生命周期并且拥有全局唯一标识(ID)的对象，比如本文中的Order和Product，而值对象表示用于起描述性作用的，没有唯一标识的对象，比如Address对象。

聚合根一定是实体对象，但是并不是所有实体对象都是聚合根，同时聚合根还可以拥有其他子实体对象。聚合根的ID在整个软件系统中全局唯一，而其下的子实体对象的ID只需在单个聚合根下唯一即可。 在本文示例项目中，OrderItem是聚合根Order下的子实体对象:

public class OrderItem { private ProductId productId; private int count; private BigDecimal itemPrice; } 可以看到，虽然OrderItem使用了ProductID作为ID，但是此时我们并没有享受ProductID的全局唯一性，事实上多个Order可以包含相同ProductID的OrderItem，也即多个订单可以包含相同的产品。

区分实体和值对象的一个很重要的原则便是根据相等性来判断，实体对象的相等性是通过ID来完成的，对于两个实体，如果他们的所有属性均相同，但是ID不同，那么他们依然两个不同的实体，就像一对长得一模一样的双胞胎，他们依然是两个不同的自然人。对于值对象来说，相等性的判断是通过属性字段来完成的。比如，订单下的送货地址Address对象便是一个典型的值对象:

值对象的不变性使得程序的逻辑变得更加简单，你不用去维护复杂的状态信息，需要的时候创建，不要的时候直接扔掉即可，使得值对象就像程序中的过客一样。在DDD建模中，一种受推崇的做法便是将业务概念尽量建模为值对象。

另外，需要指明的是，实体和值对象的划分并不是一成不变的，而应该根据所处的限界上下文来界定，相同一个业务名词，在一个限界上下文中可能是实体，在另外的限界上下文中可能是值对象。比如，订单Order在采购上下文中应该建模为一个实体，但是在物流上下文中便可建模为一个值对象。

上下文: 单词或语句在其中出现的、可以决定其意思的环境。模型的语句只能在上下文中进行理解。 有界上下文: 对边界 (通常是一个子系统或特定团队的工作) 的描述，特定模型在其中定义，同时也是模型的适用范围。

https://www.infoq.cn/article/tbHvBulrMyBA3kA5378q?utm_source=rss&utm_medium=article https://insights.thoughtworks.cn/backend-development-ddd/

DAO, Data Access Object

https://developer.aliyun.com/article/758292

演进式设计

重构是克服演进式设计中大杂烩问题的主力

有一种解决方案，按照演进式设计的理论，让系统的设计随着系统实现的增长而增长。我们不需要作提前设计，就让系统伴随业务成长而演进。这当然是可行的，敏捷实践中的重构、测试驱动设计及持续集成可以对付各种混乱问题。 重构 – 保持行为不变的代码改善清除了不协调的局部设计，测试驱动设计确保对系统的更改不会导致系统丢失或破坏现有功能，持续集成则为团队提供了同一代码库。

领域对象, Domain Object, DO

贫血领域对象

贫血领域对象 (Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象。

在我们习惯了J2EE的开发模式后，Action/Service/DAO这种分层模式，会很自然地写出过程式代码，而学到的很多关于OO理论的也毫无用武之地。使用这种开发方式，对象只是数据的载体，没有行为。以数据为中心，以数据库ER设计作驱动。分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。

软件系统复杂性应对 解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。

分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。

抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。

知识 顾名思义，DDD可以认为是知识的一种。

DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。

https://tech.meituan.com/2017/12/22/ddd-in-practice.html

我们将架构设计活动精简为以下三个层面：

业务架构——根据业务需求设计业务模块及其关系 系统架构——设计系统和子系统的模块 技术架构——决定采用的技术及框架 以上三种活动在实际开发中是有先后顺序的，但不一定孰先孰后。在我们解决常规套路问题时，我们会很自然地往熟悉的分层架构套 (先确定系统架构），或者用PHP开发很快 (先确定技术架构），在业务不复杂时，这样是合理的。

跳过业务架构设计出来的架构关注点不在业务响应上，可能就是个大泥球，在面临需求迭代或响应市场变化时就很痛苦。

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

https://tech.meituan.com/2017/12/22/ddd-in-practice.html

战略建模 战略和战术设计是站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

领域 现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文，限界上下文就是软件对于问题域的一个特定的、有限的解决方案。

限界上下文, Bounded Context

一个由显示边界限定的特定职责。领域模型便存在于这个边界之内。在边界内，每一个模型概念，包括它的属性和操作，都具有特殊的含义。

一个给定的业务领域会包含多个限界上下文，想与一个限界上下文沟通，则需要通过显示边界进行通信。系统通过确定的限界上下文来进行解耦，而每一个上下文内部紧密组织，职责明确，具有较高的内聚性。

一个很形象的隐喻：细胞质所以能够存在，是因为细胞膜限定了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。

划分限界上下文 划分限界上下文，不管是Eric Evans还是Vaughn Vernon，在他们的大作里都没有怎么提及。

显然我们不应该按技术架构或者开发任务来创建限界上下文，应该按照语义的边界来考虑。

我们的实践是，考虑产品所讲的通用语言，从中提取一些术语称之为概念对象，寻找对象之间的联系；或者从需求里提取一些动词，观察动词和对象之间的关系；我们将紧耦合的各自圈在一起，观察他们内在的联系，从而形成对应的界限上下文。形成之后，我们可以尝试用语言来描述下界限上下文的职责，看它是否清晰、准确、简洁和完整。简言之，限界上下文应该从需求出发，按领域划分。

限界上下文之间的映射关系

合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。 防腐层（Anti-corruption layer）：一个上下文通过一些适配和转换与另一个上下文交互。 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。 另谋他路（SeparateWay）：两个完全没有任何联系的上下文。

实体, Entity

当一个对象由其标识（而不是属性）区分时，这种对象称为实体（Entity）。

例：最简单的，公安系统的身份信息录入，对于人的模拟，即认为是实体，因为每个人是独一无二的，且其具有唯一标识（如公安系统分发的身份证号码）。

在实践上建议将属性的验证放到实体中。

许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。只要一个对象在生命周期中能够保持连续性，并且独立于它的属性（即使这些属性对系统用户非常重要），那它就是一个实体。

值对象, Value Objects

当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象（Value Object）。

例：比如颜色信息，我们只需要知道{“name”:“黑色”，”css”:“#000000”}这样的值信息就能够满足要求了，这避免了我们对标识追踪带来的系统复杂性。

值对象很重要，在习惯了使用数据库的数据建模后，很容易将所有对象看作实体。使用值对象，可以更好地做系统优化、精简设计。

它具有不变性、相等性和可替换性。

在实践中，需要保证值对象创建后就不能被修改，即不允许外部再修改其属性。在不同上下文集成时，会出现模型概念的公用，如商品模型会存在于电商的各个上下文中。在订单上下文中如果你只关注下单时商品信息快照，那么将商品对象视为值对象是很好的选择。

防腐层, Anti-corruption layer

亦称适配层。在一个上下文中，有时需要对外部上下文进行访问，通常会引入防腐层的概念来对外部上下文的访问进行一次转义。

有以下几种情况会考虑引入防腐层：

  • 需要将外部上下文中的模型翻译成本上下文理解的模型。
  • 不同上下文之间的团队协作关系，如果是供奉者关系，建议引入防腐层，避免外部上下文变化对本上下文的侵蚀。
  • 该访问本上下文使用广泛，为了避免改动影响范围过大。

领域服务, Domain Services

一些重要的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。

当我们采用了微服务架构风格，一切领域逻辑的对外暴露均需要通过领域服务来进行。如原本由聚合根暴露的业务逻辑也需要依托于领域服务。

我们将领域行为封装到领域对象中，将资源管理行为封装到资源库中，将外部上下文的交互行为封装到防腐层中。此时，我们再回过头来看领域服务时，能够发现领域服务本身所承载的职责也就更加清晰了，即就是通过串联领域对象、资源库和防腐层等一系列领域内的对象的行为，对其他上下文提供交互的接口。

领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。 当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务。有时我们倾向于使用聚合根上的静态方法来实现这些这些操作，但是在 DDD中,这是一种坏味道

信息传输对象（DTO）

数据库持久化对象（PO）0

用DDD则可以很好地解决领域模型到设计模型的同步、演化，最后再将反映了领域的设计模型转为实际的代码。

注：模型是我们解决实际问题所抽象出来的概念模型，领域模型则表达与业务相关的事实；设计模型则描述了所要构建的系统。

在我们习惯了J2EE的开发模式后，Action/Service/DAO这种分层模式，会很自然地写出过程式代码，而学到的很多关于OO理论的也毫无用武之地。使用这种开发方式，对象只是数据的载体，没有行为。以数据为中心，以数据库ER设计作驱动。分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。

按照我们通常思路实现，可以发现：在业务领域里非常重要的功能，业务逻辑都是写在Service中的，类充其量只是个数据载体，没有任何行为。简单的业务系统采用这种贫血模型和过程化设计是没有问题的，但在业务逻辑复杂了，业务逻辑、状态会散落到在大量方法中，原本的代码意图会渐渐不明确，我们将这种情况称为由贫血症引起的失忆症。

更好的是采用领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

软件系统复杂性应对 解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。

分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好，即高内聚低耦合。

抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。

知识 顾名思义，DDD可以认为是知识的一种。

DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。

与微服务架构相得益彰 微服务架构众所周知，此处不做赘述。我们创建微服务时，需要创建一个高内聚、低耦合的微服务。而DDD中的限界上下文则完美匹配微服务要求，可以将该限界上下文理解为一个微服务进程。

架构设计活动精简为以下三个层面：

业务架构——根据业务需求设计业务模块及其关系 系统架构——设计系统和子系统的模块 技术架构——决定采用的技术及框架

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

设计领域模型的一般步骤如下

  • 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
  • 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
  • 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
  • 为聚合根设计仓储，并思考实体或值对象的创建方式；
  • 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

战略建模 战略和战术设计是站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

领域 现实世界中，领域包含了问题域和解系统。一般认为软件是对现实世界的部分模拟。在DDD中，解系统可以映射为一个个限界上下文，限界上下文就是软件对于问题域的一个特定的、有限的解决方案。

应用服务

限界上下文, Bounded Context, BC

模块, Module

模块（Module）是DDD中明确提到的一种控制限界上下文的手段

通用上下文

领域事件, Domain Events

资源库, Repository

https://tech.meituan.com/2017/12/22/ddd-in-practice.html

https://developer.aliyun.com/article/2255?spm=a2c6h.12873639.0.0.4f0121d9i6g8vv

https://domain-driven-design.org/zh/ddd-concept-reference.html

https://cloud.tencent.com/developer/article/1791703

https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html

https://docs.mryqr.com/ddd-introduction/

实现业务逻辑的三种方式

事务脚本

事务脚本(Transactional Script)，也即通过类似编写脚本的方式完成一个业务用例，一个业务用例对应一次事务。

贫血对象

只有数据没有行为的对象被称为贫血对象。