一.先弄清楚业务流程，捋清业务界限然后才能进行技术设计
捋清楚业务界限和方向，再进行微服务的划分，数据模型（业务信息主体）的确定，然后在业务实现和不同业务交互的过程中再引入队列、缓存、搜索、数据库等技术，然后再基础设施建设监控、安全
对于水平层面结构的划分，应该根据系统规模的需求
参考到家设计
重点看看极客时间 怎样设计聚合
有效降低层与层之间的依赖
二.基本的水平结构：
web层（包括前端）、应用层（跨领域服务）、领域层（是聚合内容，跨实体）、数据层
三、DDD中的实体对象和值对象
实体对象：有唯一标识的对象，拥有id，其他属性变了id不变仍能确定是这个对象
值对象：没有唯一标识，一旦属性发生变化表示的就是另外一个对象，单个的值，字典
判断是不是同一个对象的依据
实体对象：id； 值对象：值
DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变，减少数据库表的数量和表与表之间复杂的依赖关系，尽可能地简化数据库设计，提升数据库性能。在整个系统中二者根据具体的业务需求来确定，可以同时采用
将数据主体设置成值对象还是实体对象，主要看这个对象是当做主体来用还是当做字典来用，像同样是地址，当做为“收货地址”来用 可以设置成值对象，当做为“商圈”来用 可以做成实体对象 一个城市就有五个商圈 商圈是一个主体
跨实体的业务通过领域服务来实现（领域层），将业务需要的实体聚合到一起也可以称为聚合服务这个过程坚持“高内聚，低耦合”，跨多个聚合的服务通过应用层来实现
三、微服务解耦的关键：异步
领域事件需要数据交互 可以通过分布式事务和队列两种方式
微服务内部可以采用分布式事务
微服务之间可以采用 异步 消息队列
四、降低层与层之间的依赖
定义好聚合之间的界限，降低层与层之间的耦合
跨聚合应该是应用层
每一层只能与其下方的一层发生耦合
微服务存在重组和拆分：
微服务之间有拆分和重组，微服务内部也有拆分和重组
拆分：
1.某个聚合经常被高频访问，可以考虑拆分为独立的服务（new-cpassport）
2.像服务1中的聚合b，随着业务的发展可以放到服务2中去
重组：
1.比如领域服务a、b、c，随着系统外部接入的越来越多，发现b和c服务同时多次被一个应用服务调用了，执行顺序也基本一致，可以考虑将b和c服务合并，再将应用服务中b和c的功能下沉到领域层，演进成新的领域服务（b+c）。
四.中台建设
中台概念的形成是企业将原来分散的系统想要形成一个闭环生态，生态需要共有的数据将各系统链接起来，这样产生了公共的数据和公共的业务，将这些公共的内容向下沉淀抽取形成了中台，中台本身的定义就是“企业级能力的复用平台”，在形成中台的过程中有两个方向，通用中台（偏向工具）、核心中台（偏向企业的核心数据）。
1.中台是不是仅仅是个Dao层？
（1）.数据中台是领域服务的一种体现
（2）.并不是简单的提供对单表数据的增删改查，需要体现聚合的概念，像创建某个业务数据时，需要将这个业务的所有数据作为参数传入中台服务接口，由中台服务分发各个数据到对应的表中；当查询时只需提供一个聚合根也就是业务id，由中台服务组装所有表的数据然后返给调用方
（3）.如果业务方一个服务需要同时调用中台多个服务，这时可以提供一个适配层服务，对外只是一个接口，由适配层来调用多个中台服务完成业务流程
以上能保证核心的数据和核心的业务在中台，也实现中台的模块化，提高了与业务系统的解耦
2.中台拆分的考虑
中台也分核心中台和通用中台，核心中台是核心的竞争力核心的数据，通用中台是通用的功能
在拆分的时候考虑 元素单元：是否是同一个业务内的数据
数据特征：像登录，name 、password、账号（访问高、不轻易变动的数据）是一个表，，登录次数，时间，记录（访问量不高，变化多）的数据是一个表，，，这样能防止锁表锁行，提高执行效率
《企业IT架构转型之道：阿里巴巴中台战略转型思想和实战》
3.中台的作用
（1）进行数据和功能的复用，防止重复性开发，简化上层代码，同时也单独维护了通用业务逻辑和核心的数据
（2）对于家政来说，现在的中台功能（商家中心，支付中心，订单中心）非常完备，如果出现了一个新的家政类型（不是保洁、保姆、月嫂），这时候只需要开发上层业务场景代码就能直接实现这个功能，不需要底层开发
五、DDD设计案例