微服务拆分
方法论
领域驱动设计 (Domain-driven design)
核心
将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域。
分层架构
大的层次上分为四层
api：用户界面层(或表示层)，向外提供服务，负责向用户显示信息和解释用户指令。
app：应用层，包含应用服务，负责用例流程调度，事务控制。不包含业务规则或者知识，而只为下一层中的领域对象协调 任务，分配工作。
domain：领域层，包含领域对象和领域服务，专注核心业务，负责表达业务概念，业务状态信息以及业务规则。
infra：基础设施层，提供数据持久化、防腐层实现、第三方库、消息等。为上面各层提供通用的技术能力:为应用层传递消息，为领域层提供持久化机制， 为用户界面层绘制屏幕组件，等等。
特点
强调“重视设计、建模”，学习曲线高，概念较多（例如问题空间、限界上下文、聚合根实体、VO、Service、工厂）。目前在国内不是主流，不过变得越来越流行。
推荐书籍
- DDD开山鼻祖——《领域驱动设计》 （主要是理论，实现比较少）
- 《实现领域驱动设计》（大量代码演示）
数据驱动和领域驱动对比
领域驱动设计与之前的系统设计开发过程有很大的不同：
- 就在于系统的参与角色，产品、开发、测试等，需要形成一套通用语言；
- 在于方案设计不再把db设计放在一个核心问题去解决，更加专注于业务模型本身，进行领域、业务聚合的设计，领域层的聚合及实体才是整个系统的核心内容；
- 真正的面向对象编程，由过程式的事务脚本方式，转变为真正的面向对象。
微服务拆分-合理的粒度
良好的满足业务
幸福感
增量迭代
持续进化
个人心得
在我看来，微服务拆分分为两个维度：
职责划分：例如订单服务应该只关注订单相关的业务，其他的业务不应该放到这里。
通用性划分：把一些通用功能做成微服务，例如：用户中心、消息中心等等
