绪论
设计原则千万条，高聚松耦第一条，
架构设计不规范，开发运维两行泪！
1.单体架构
在单体架构之前的上古时代，所有的东西（应用程序，文件系统，数据库，web）都被部署并运行在一台服务器上，随着业务逻辑的逐渐复杂，数据存储开始变的低效，整个系统全部揉杂在一起，相互影响，耦合度极高。
随着软件规模的扩大，单台服务器已经不能满足软件运行的需求，开始出现了软件的单体架构。单体架构的风格就是简单意味着一个程序中包含着整个系统所有模块的所有功能，这个应用程序被部署并运行在单一结点的单一进程中。
优点：项目容易管理，部署简单，易于水平扩展
缺点：模块耦合度高，稳定性差，迭代困难，全功能团队开发效率低
例如打成java war包运行的网站。
2.分层架构
分层架构的核心是每一层都依赖于它之下的层，和它之上的层无关，对使用（依赖）他的层次是没有感知的
2.1MVC
mvc架构
控制器（Controller）- 负责转发请求，对请求进行处理。
视图（View） - 界面设计人员进行图形界面设计。
模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
2.2MVVM模式
mvvm模式
mvvm模式中采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然 更多的用于前端
2.3EBI模式
功能性数据驱动架构EBI（ Entity-Boundary-Interactor）
实体Entity是架构的核心。实体表示具有独立于应用程序的业务规则的业务对象。所有与应用程序无关的业务规则都应位于实体中。
边界Boundary是与外界的联系。边界可以实现用于处理图形用户界面或web API的数据的功能。边界本质上是函数性的：它们接受数据请求并产生响应。
交互者Interactor操纵实体。他们的工作是通过边界接受请求并操纵应用程序状态。Interactors是应用程序的业务逻辑层。
更关注后端如何组织
2.4DDD
领域驱动设计，一种设计思想
用户接口 负责绘制用户用来和应用交互的屏幕界面并将用户的输入翻译成应用的命令。它们和EBI架构中的边界对象完全对应。
应用层 协调领域对象完成用户要求的任务。它不包含业务逻辑。应用层和EBI架构中的交互器相对应，只有一点不同，交互器是和界面或实体无关的任意对象，而这里应用层只包含和用例相关的对象。
领域层 这个层次包含了所有的业务逻辑，如领域服务、实体、事件和其他包含业务逻辑的任意对象类型。显然它和 EBI 架构中的实体对象类型对应。领域服务摆包含的领域逻辑通常是多个实体进行的编配。
基础设施 支持上述三个层次的技术能力，例如，持久化或者消息机制。
2.5六边形架构（端口适配器架构）
六边形架构
系统中真正重要的是位于中间的层次”。业务逻辑(应该)存在于这些层次之中
顶部和底部的层次从另一方面来说，就是应用的入口/出口，两侧都可能有若干入口/出口。
例如， API和UI就是位于应用左侧的两个不同的入口/出口。为了表示应用有若干个入口/出口，我们把应用的形状改成了多边形。应用的形状可以是有多条边的任意多边形，但最终六边形获得了青睐。这也是“六边形架构”的由来。
什么是端口？
端口是对其消费者无感知的进入/离开应用的入口和出口。在许多编程语言里，端口就是接口。例如，在搜索引擎里它可能是执行搜索的接口。
什么是适配器？
适配器是将一个接口转换(适配)成另一个接口的类。
在左侧，适配器依赖端口，该端口的具体实现会被注入到适配器，这个实现包含了用例。换句话说，端口和它的具体实现(用例)都在应用内部。 在右侧，适配器就是端口的具体实现，它自己将被注入到我们的业务逻辑中，尽管业务逻辑只知道接口。换句话说，端口在应用内部，而它的具体实现在应用之外并包装了某个外部工具。
2.5洋葱架构
洋葱架构
它在端口和适配器架构的基础上贯彻了将领域放在应用中心，将传达机制(UI)和系统使用的基础设施(ORM、搜索引擎、第三方 API...)放在外围的思路。它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次。
六边形架构和洋葱架构
不同点：从6边形到圆
相同点：外层依赖内层；内层对外层无感知。
2.6整洁结构
整洁架构
依赖规则(Dependency Rule)
用一组同心圆来表示软件的不同领域。一般来说，越深入代表你的软件层次越高。外圆是战术是实现机制(mechanisms)，内圆的是核心原则(policy)。
实体 (Entities)
实体封装的是整个范围内的业务核心原则(policy)，
用例 (Use case)
在这个层的软件包含只和应用相关的业务规则，它封装和实现系统的所有用例，
接口适配器 (Interface Adapters)
这一层的软件基本都是一些适配器，主要用于将用例和实体中的数据转换为外部系统如数据库或Web使用的数据
框架和驱动器
最外面一圈通常是由一些框架和工具组成，如数据库Database, Web框架等
整洁架构只是一种术语上的称呼，洋葱架构是对这种称呼中概念解释的一种特殊应用
3.事件驱动架构
事件（event）是状态发生变化时，软件发出的通知。
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
分发器（event mediator）
核心：解耦
设计实例：可靠事件中心
4.插件架构
微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
核心：功能延伸
设计实例：IDEA编译器
5.CQRS
命令查询职责分离（Command Query Responsibility Segregation）
命令(Command):
不返回任何结果(void)，但会改变对象的状态。
命令操作会直接修改数据库，并针对多个领域模型的情况下我们需要增加来保证操作的原子性。而对于一个命令操作，我们往往是不直接依赖命令的返回值的，所以通常可以异步执行命令操作。对于一般系统来说，往往命令操作的使用频次会较低。
查询(Query):
返回结果，但是不会改变对象的状态，对系统没有副作用。
查询操作并不会修改数据库中的内容，所以查询本身是一种幂等操作，以同一个查询条件在系统不改变的情况下反复执行会返回相同的结果，我们可以针对这种特性提供数据缓存来提高系统性能；同时因为不影响数据库，查询逻辑是不会产生数据一致性问题。查询往往会存在较高的使用频率。
核心：读写分离
6.SOA微服务架构云架构
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。比SOA拆的更细。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议联系。
核心：高内聚 松耦合
设计实例：hsf体系
7.云架构
消息中间件（Messaging Grid）：
管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
数据中间件（Data Grid）：
将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
处理中间件（Processing Grid）：
可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
部署中间件（Deployment Manager）：
负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。数据量小，而每个计算很耗时。
核心：动态部署
设计实例：云原生，k8s
参考文章：
https://stackoverflow.com/questions/23479879/clean-architecture-vs-onion-architecture
https://yuque.antfin.com/wt0u0d/apxaqv/gdknp2
