软件的架构设计，就是选择和取舍
故障隔离
特别是在开发MVP场景时，初创公司的出版应用程序是用来获取市场和投资人的反馈、进行快速试错的，这个阶段不应花费太多时间在微服务架构这样的事情上。 —译者注
康威定律 设计系统的组织……往往被组织的架构所限制，最终设计的结果是这些组织的沟通结构的副本。
计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。 —Bass等著 这显然是一个非常抽象的定义。但其实质是应用程序的架构是将软件分解成元素和这些元素之间的关系。由于以下两个原因，分解很重要： 它促进了劳动和知识的分工。它使具有特定专业知识的人们（或多个团队）能够就应用程序高效地协同工作。 它定义了软件元素的交互方式。
业务逻辑的周围是适配器
六边形架构是描述微服务架杨中每个服务的架构的好方法。
定义架构也是一项艺术而非技术。
定义应用程序架构的第一步是定义操作系统 第一步创建由关键类组成的抽象领域模型，这些关键类提供用于描述操作系统的词汇表。 第二步确定操作系统，并根据领域模型描述每个系统操作的行为。
DDD两个特别重要的概念，子域和限界上下文。
微服务有两种构建模式 1 业务能力 2 领域驱动
进程间通信 同步和异步
接口定义开发流程 首先编写接口定义，然后与客户端开发人员一起查看这些接口定义。只有在反复迭代几轮API定义之后，才开始具体的服务实现编程。这种预先设计有助于你构建满足客户端需求的服务。
API优先设计 健壮性原则，版本兼容原则
REST成熟模型 四个等级
断路器
Saga CAP原理证明，对于分布式系统来说，只能够在它的一致性、可用性和分区容错性这三个属性中同时保证两个。
补偿机制，在服务链中，如果当前服务执行错误，则需要将之前的数据变更回滚操作。 协同式
编排式 把Saga编排器视为一个状态机
对象化为聚合，当处理某一对象时，需要将所有与之关联的对象做相应操作处理。
在领域设计驱动，设计领域模型的关键部分是识别聚合，以及他们的边界和根。
聚合的规则 领域驱动是设计要求聚合遵守一组规则。这些规则确保聚合是一个可以强制执行各种不变量约束的自包含单元。
规则1:只引用聚合根 规则二：聚合间的引用必须使用主键 规则三：在一个事务中，只能创建或更新一个聚合

阻抗失调
事件溯源
事件事务