DDD不是贫血模式、充血模式、成为领域专家。
DDD本质是高内聚低耦合、是一个设计的方法，并没有对应的框架
现在我们拿电商平台举个栗子，阐述下什么是领域设计
一级领域：用户 商品 交易 营销 搜索
二级领域： 用户--- 登录、注册、查询 交易--下单、查询 搜索--用户、订单
三级领域：很少、很少.......
领域设计的主要切入点:微服务架构
微服务架构如何落地？
本质上就是拆，在业务侧 领域驱动设计。 在架构侧，水平拆分。
企业级微服务架构的方法论
用户侧:我们可以将读和写分为两个子领域。按照二级领域拆分。
由于db还是一个表，问题还是没解决。通过主从同步，(刚注册完就来查询数据还没同步)但是同步是异步的会造成数据的不一致。那又是一个问题。怎么解决？1.查询强制主库，一但读写量超过请求范围，服务崩溃。2。同步式的同步，等写入从库之后在在返回响应,会影响性能。3.主库可以切分 变成N个，然后去查询从库减少压力。
那是不是登录和注册是不是都要领域的划分？还是一个宗旨：一切脱了业务的设计都是耍流氓。同样 搜索也可以分为查询的搜索、建立索引的搜索
下面我们拿商品服务来举例，在架构侧的分层框架：
企业级的微服务实践方法论:
拿一个二手交易的微服务实践
进一步优化架构，将业务逻辑服务裂变成业务逻辑层和公共逻辑层。衍生出来了业务中台的概念。为什么要这么设计呢？比如不管是手机商品、图书商品都是商品，都是要发布，那这就是通用的功能，同样商品的搜索逻辑、推荐服务。以此类推，数据访问服务也一样，商品发布数据访问、商品搜索数据访问服务都可以下沉为公共访问服务。注意：同层之间是不能相互调用。
上面两图就差不多是我们普适的微服务架构。然后下面又有疑问：这是同步架构还是异步架构？
企业级微服务架构同步/异步设计
左图就是同步场景，不能满足所有场景。
场景分为CP和AP场景。比如你在微信聊天和发红包哪个操作比较多。所以说明CP并发偏小，AP场景并发大。
右图多在于AP场景。类似于我们支付宝充话费，你付款后，支付宝会给你一条消息，正在充值中....,过一段时间才会通知你是否成功。如果不是，你直接返回充值成功，实际在业务层到数据访问层出错了，又告诉用户充值不成功，你是不是要疯！这种架构，你的公司离倒闭就差一次大金额的支付。
同样，微信也是这样，你发送一条朋友圈，过一段时间才会通知你是否成功。