架构风格

前两篇文章讲的是架构分类和技术架构，这篇文章继续深入探讨架构风格中相关的概念以及区别。本文以微服务为思考点，以微服务和DDD为连接点，梳理出两条线：微服务前后历史线以及DDD前后历史线，这样我们可以看清发展的架构发展的过程。

先抛出两条线的图：

架构风格

1. 单体架构的应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加，越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。

2. 客户端/服务器体系结构将大多数逻辑放在服务器端，并将某些处理放在客户端上。客户端/服务器是分布式计算中首次尝试取代大型机作为业务应用程序的主要托管模型。

3. 中级架构，分布式应用，中间层分布式+数据库分布式，是单体架构的并发扩展，将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也大量采用分布式数据库，如redis、ES、solor等。通过LVS/Nginx代理应用，将用户请求均衡的负载到不同的服务器上。

4. 微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有Spring cloud、Dubbo等。

5. Serverless架构能够让开发者在构建应用的过程中无需关注计算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的SLA（服务等级协议），按照调用次数进行计费，有效的节省应用成本。

架构模式

下边这条线为DDD的发展线，分别为过程建模、数据建模以及领域建模，这三个方式和上一条线中的几种方式相互交叉

1. 过程建模：直观思维，关注特定功能的描述过程，功能的重用性被忽略。
2. 数据建模：归纳思维，关注功能的复用性和数据范式，缺乏对数据的封装，忽略上下文对数据的影响，面向功能模块复用的过程构建。
3. 领域建模：抽象思维，功能和数据聚合抽象成实体，同等关注功能与数据的重要性和封装性

参考地址：
https://blog.csdn.net/moxiaoya1314/article/details/51899048
https://blog.csdn.net/maoyeqiu/article/details/104463639
https://crimsonromance.github.io/2019/03/23/%E5%9B%9B%E7%A7%8D%E8%BD%AF%E4%BB%B6%E6%9E%B6%E6%9E%84%EF%BC%9A%E5%8D%95%E4%BD%93%E6%9E%B6%E6%9E%84%E3%80%81%E5%88%86%E5%B8%83%E5%BC%8F%E6%9E%B6%E6%9E%84%E3%80%81%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E3%80%81Serverless%E6%9E%B6%E6%9E%84/