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、梳理架构体系

业务架构，应用架构，技术架构，数据架构，部署架构。

不可避免的代码腐化是指软件开发过程中，由于需求的不断迭代、技术债务的累积以及架构设计的局限性，代码质量逐渐下降的过程。

当系统变得复杂，功能之间会逐渐产生耦合，它们的关联关系也会变得复杂。这些无意间引入的耦合，会给后续所有的需求开发增加一些额外的负担。

架构设计和模块抽象只能面向当下，它天然是短视的或者说是有局限性的。

腐化除了来自开发者低质量的代码，更核心的是来自于系统架构的腐化。

瀑布式开发：按顺序开发，周期长。

敏捷开发：是部分开发，挑重点开发，因为开发是局部，不能统筹全局，所以当下的架构就会失效，出现代码腐化。需求本身就是零散的，目标也是模糊的。在没有全局视图的情况下，架构自然就是有局限的，只能适应当下。而随着项目的发展，只能适应当下的架构就会失效。

该分离的分离，该提取的提取，进行逻辑抽象，功能封装，能力下沉，多系统复用。