从18年团队开始转型微服务架构，会想起来，总结2个字，就是“生拆”。只要是能够独立的业务模块或是可复用的组件，都拆成一个个微服务。这样，原本的单体项目，拆成了23个微服务，而我们当初维护的团队，仅仅才5～6个人。
18年底，docker-compose管理3～4个服务。
19年中，kubernates管理20+个业务服务，不包括基础服务在内。
回想起来，一次失败的尝试，换来的是坑与、敬畏和不屈。后来极客上了DDD，很早就听了一遍，有触动，但是感觉还是不强烈，从今天开始重学DDD，拿一个业务模型进行拆解设计，也算是立个flag。
DDD的概念主要包括：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对象、聚合和聚合根。
领域和子域
领域就是指范围，它是用来限定业务边境的，领域越大，业务范围就越大。领域可以进一步进行拆分，拆分后的就是“子域”。
子域对应的一个更小的问题域或更新的业务范围。
核心域、通用域和支撑域
在领域的划分过程中，领域会细分为不同的子域，子域根据其重要性和自身的功能特点，划分为3类子域，就是核心域、通用域和支撑域。这3个概念的主要目标就是区分子域在业务中不同的功能属性和重要程度。
公司的核心竞争力是核心域，同时被多个子域使用的通用功能子域是通用域，即不是核心域也不是通用域，但是是必须的，就是支撑域。通用域一般没有太多的个性化，比如：认证、权限等。支撑域则有企业特性，但是不具有通用性，例如数据字典等。
限界上下文
理论上，限界上下文就可以定义成微服务。限界上下文是微服务拆分的主要依据
实体
实体的4种形态分别是：业务形态、代码形态、运行形态和数据库形态。
- 业务形态，实体是多个属性、操作或行为的载体；
- 代码形态，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑，特别注意在DDD中，实体类通常采用的是充血模型
- 运行形态，实体以领域对象的形式存在，每个对象都有唯一的ID，我们可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的 ID，它们依然是同一个实体。
- 数据库形态，与传统数据模型设计优先不同，DDD 是先构建领域模型，针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。
值对象
值对象，通俗的讲，就是一个子对象和一组属性集合。它没有唯一的标识，依赖一个实体存在。比如用户的学历信息、地址信息都是值对象。
-
代码形态，在代码中有2种形态。如果值对象是单一属性，就直接定义成实体类的属性；如果是属性集合，就把它设计成类，被实体引用。如下图
image - 运行形态，如上图所示就写了。
- 数据库形态，在数据中，值对象可以是单独的数据表，也可以采用大字段的方式嵌入到实体表中。至于数据库是何种设计方式，我认为是和业务博弈的一种结果，设计成大字段，减少了维护成本和结构复杂度，但是不利于做一些特有的业务操作，比如单个属性查询。
聚合和聚合根
聚合和聚合根感觉抽象一些，等具体落地验证后再补充。
