业务逻辑设计与组织
组织模式：
- 入站适配器处理客户端请求并调用业务逻辑
- 出站适配器被业务逻辑调用，进而调用其他服务
对于简单的业务逻辑，使用简单的解决方式：事务脚本模式
事务脚本模式只适用于简单的业务逻辑，是一种过程式的代码。当业务逻辑逐渐复杂，则就准备使用领域模型，这种模式是将业务逻辑组织为具有状态和行为的对象模型。
领域驱动设计是构建复杂业务逻辑最后利器，它提供了诸如entity valueobject factory repository service等概念都已经被现在的开发人员广泛采用，但对微服务最重要的概念，还是DDD中的聚合。
聚合模式
业务逻辑必须仔细设计，以保障全局的一致性，为了维护这种一致性，将各个领域模型组织成聚合，每组聚合就是一个边界，聚合外的模型只能通过聚合根来进行交流。
一些规则：
- 只引用聚合根：就是只跟根打交道，这样可以通过仔细设计根的方式保证单一出入口
- 聚合间的引用通过主键：通过主键让持久化与扩展变得简单
- 一个事务中，只能更新或创建一个聚合：这是为了满足微服务场景下分布式事务的问题，此时可以使用Saga
聚合的粒度越细会越有扩展性，但粗一点的聚合也有降低编程工作量的好处，更粗的聚合，一次可以操作更多的模型。
领域事件
领域事件指的是一般是过去的时候模型发生了某些状态变化或者执行了某些操作等。
领域事件由聚合负责发布。作为事件，同样也得满足事务的特征同时被可靠地发布。
事件发布之后，则可以通过消息代理被各方消费。
事件溯源
对对象记录事件状态产生的变化，需要对象时对这些事件进行重放
为了避免重放事件带来的效率问题，常见的解决方案是定时保存对象快照
好处：
- 可靠发布领域事件
- 保留了变更历史
- 最大程度避免阻抗失衡
弊端：
- 有一定学习曲线
- 基于消息传递应用的复杂性
- 随着代码演进状态发生变更就必须兼容以前版本
- 删除与查询变得不再容易