这书不是一本理论书，这是一本实操手册。
先说理论：
架构=>架构建模=》架构风格=》分层架构/六边形架构=》单体架构/微服务架构。
摘录两句：
计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素，他们之间的关系以及两者的属性。
《Documenting Software Architectures：View and Beyond》
仅凭这句话，就有阅读这书的冲动呀。
架构建模，可以查阅关于4+1视图
架构风格根据结构组织模式定义了一系列此类系统。更具体的说，架构风格确定可以在该风格的实例中使用的组件和连接器的词汇表，以及关于如何组合他们的一组约束。
看这个解释，Chris在该书说中使用了所有模式就构成了微服务架构风格的词汇表，如果能默写名词解释，估计也可以吹一吹了。
传统分层结构，一般是3层，表现层/业务逻辑层/数据持久化层。有时也为了防腐，增加一层。
DDD中就使用六边形架构，主要体现为关注领域核心概念，出入口都是通过adapter来对接。六边形是虚数，估计是DDD作者恰巧了。
以上其实都是单体架构，与之对应的就是微服务架构，现在服务和微服务并没有区分的很清楚，一般一个服务下有一个微服务，逻辑视图也没有严格区分。
微服务不代表大小，但是这个用词其实有一些不成文的约束。现在我们倒是有些要求，比如启动时间10s，关闭时间5s，其实恰恰是对微服务大小的约束。单个微服务Charis同样推荐使用六边形架构。
再说实操：
如何定义微服务架构。
定义系统操作==》定义服务==》定义服务API和协作方式
定义系统操作：
定义：系统操作是应用程序必须处理的请求的一种抽象描述。
步骤：创建领域模型==》定义系统操作
创建领域模型：分析用户故事和场景描述描述中频繁出现的#名词。
定义系统操作：识别系统执行的切入点是分析用户故事和场景描述中的#动词。
定义服务：
根据业务能力进行服务拆分
所有的软件产品都是为业务服务，业务如果不赚钱，说破了天也没用。我是工作了3年才悟透了这个道理。
每个业务能力或者相关业务能力组织成一个微服务。根据子领域进行业务拆分
DDD中子领域作为拆分标准。核心还是业务概念的分组。
拆分的指导原则：
单一职责原则
闭包原则：在包中包含的所有类应该是对同类的变化的一个集合，也就是说，如果对包做出修改，需要调整的类应该都在这个包内。
这两个原则基本对软件的放方面适用。
拆分的阻碍：
- 网络延迟 =》 性能问题
- 同步进程间通信导致可用性降低 ==》可靠性问题
- 数据一致性
- 获取一致的数据视图 =>这只是个展示，跟上面问题也是相关的
5.上帝类 ==》这是编码问题，这个在单体应用中仍然是问题。
这是微服务设计过程中最大的几个问题，剩下的就是权衡，是没办法全部解决的。参考CAP，BASE， 不可能原理。
定义服务API和协作方式：
API有命令和查询之分，主要还是CRUD。对外发布事件也是API。
处理系统操作，系统操作分解的对其他服务的依赖就是其他服务的API。
看吧，这就是本实操手册。
#2020/11/21 晚
