架构总结记录
1、架构模型解决的共同问题
1.1、高内聚低耦合：解耦外部依赖，分离业务复杂度和技术复杂度等。
1.2、信息孤岛和数据壁垒：单体架构垂直，没有相互调用和复用。逻辑抽象、能力下沉、多系统复用问题
1.3、熵增
2、单体架构与分布式架构的核心区别在于
2.1、系统结构与部署
单体架构：一个代码库独立部署，初始开发简单，代码臃肿w维护困难。
分布式架构：拆分为多个独立服务，可独立开发和部署，，
2.2、耦合度
单体架构：耦合程度高，维护困难。
分布式架构：服务拆分降低耦合度，提高开发效率
2.3、扩展性与性能
单体架构：扩展时需整体复制，资源利用率低。
分布式架构：按需扩展特定服务，适合高并发大数据处理。
3、业务系统的复杂性
业务系统的复杂性，可能来自于多个放面：
1、业务复杂性
2、技术复杂性
3、历史负债，代码腐化
无论是哪种情况带来的复杂性，可以从下面几个当面来熟悉复杂的业务系统：
1、梳理架构体系。业务架构、应用架构、数据架构（领域模型）、技术架构、部署架构构成整个系统的架构体系，缺一都会影响对系统的全局性认识个把控。
2、了解业务流程。这个其实在梳理业务系统的时候，核心的业务流程应该就已经覆盖过了。但业务不只有核心流程，一些重要流程也是需要了解和梳理，有助于对系统更细致的了解。
4、屎山代码/技术债
4.1、功能之间隐秘增加的耦合、
4.2、不可避免的代码腐化
不可避免的代码腐化是指在软件开发过程中，由于需求的不断迭代、技术债务的累积以及维护不善等原因，代码质量逐渐下降，变得难以理解和维护的现象。
4.3、熵增
5、业务规模停滞结果(业务复杂度带来的结果)
5.1、不断地拓展产品的边界，创造用户价值
5.2、优化现有系统，提升用户体验。
5.3、好的技术架构和合理的模块划分方案，考虑到可复用性可以减少成本
6、软件开发的增效
6.1、工程效能(业务开发占比和非业务开发占比)
6.2、运营提效
Essential Complexity(本质复杂性)
Accidental Complexity(偶然复杂性)
7、复杂度
7.1、业务复杂度
业务流程复杂，业务模型复杂，业务规则负责
7.2、技术复杂度
高并发，高可用，高性能
8、平台与中台的核心区别
平台侧重技术基础设施的搭建，提供通用能力支撑；
中台则强调业务能力的沉淀复用和新业务孵化，通过组织架构调整实现快速响应和创新支持。
中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。中台是支持多个前台业务且具备业务属性的共性能力组织，平台是支持多个前台或中台业务且不具备业务属性的共性能力。
9、熟悉复杂的业务系统
1、熟悉业务流程
用户是谁，提供的核心功能是什么？产品的边界，产品族有哪些，系统的上下游调用关系。
2、梳理架构体系
业务架构，应用架构，技术架构，数据架构，部署架构。
不可避免的代码腐化是指软件开发过程中，由于需求的不断迭代、技术债务的累积以及架构设计的局限性，代码质量逐渐下降的过程。
当系统变得复杂，功能之间会逐渐产生耦合，它们的关联关系也会变得复杂。这些无意间引入的耦合，会给后续所有的需求开发增加一些额外的负担。
架构设计和模块抽象只能面向当下，它天然是短视的或者说是有局限性的。
腐化除了来自开发者低质量的代码，更核心的是来自于系统架构的腐化。
瀑布式开发：按顺序开发，周期长。
敏捷开发：是部分开发，挑重点开发，因为开发是局部，不能统筹全局，所以当下的架构就会失效，出现代码腐化。需求本身就是零散的，目标也是模糊的。在没有全局视图的情况下，架构自然就是有局限的，只能适应当下。而随着项目的发展，只能适应当下的架构就会失效。
该分离的分离，该提取的提取，进行逻辑抽象，功能封装，能力下沉，多系统复用。