当一个程序很容易地运行,有可能在同样设备上也有其它程序运行。但是，如果所有正在运行的程序需要内部通讯怎么办？这是由该程序的架构来解决这个问题。一个程序架构是一种设计的结构,在设计时就要考虑相互通讯方案，两个程序通讯也许中间需要经历许多相互等待的阶段，因此，当你使用你喜欢的任何语言编写这种程序时，必须要记住，程序必须遵循的架构，如线性编程(顺序编程)，也就是说所有的步骤要遵循一个接一个的顺序，这当然会付出执行时间的代价。另一方面，当所有的步骤都是并行执行，并在最后一步全部完成时，所需的累积(cumulative )时间是相当少。因此，最好的架构是至少有一个累积等待阶段。
但是，这并不意味着线性编程就没有用而总是使用并行架构。重要的是要知道最好的几种可能的架构，这样您可以轻松地创建一个适合所有要求的优化方案。
Clean架构
外圈的层次可以依赖内层，反之不可以，内圈核心的实体代表业务，不可以依赖其所处的技术环境。
DCI架构
本站中文DCI架构专题，DCI代表Data, Context, Interaction。
DDD/CQRS 领域驱动设计
Domain Code Design（DDD）
领域驱动设计。
DDD中有工厂和仓库来管理领域模型，前者主要用于创建，而后者则用于存储。这就表明在DDD中是默认将读写分离的，DDD似乎就天生和CQRS有着无缝的链接。
CQRS往往要求数据库进行读写分离，具体来说，所有的更新操作均无返回值(void)，而读操作才返回对应的值。
Command Query Responsibility Segregation（CQRS）
命令（增删改）和查询的责任分离。
图片摘自微信公众号：coderising
- Command: 改变对象或者系统的状态。
触发命令是唯一改变系统状态的方法。命令负责引起所有的对系统的改变。如果没有命令，系统状态保持不变！ - Query: 返回结果，并不会改变对象的状态。
查询是一个读操作。它读取系统的状态，过滤，聚总，以及转换数据，并将其转化为最有用的格式。它可以执行多次，而且不会影响系统的状态。
Command 命令端
由于读取端已经被分开，doamin(也就是写入端)只关注处理命令。现在的领域对象对象不再需要公开的内部状态。储存库除了除了GetById只有几个查询方法。
Query 端
查询将只包含获取数据的方法。从架构的角度来看，这些将是在屏幕上显示客户消费返回DTOs(数据传递对象)的所有方法。DTOs直接来自使用一个read层的数据存储。在某些情况下，它可能是一个非常痛苦的过程，尤其是当要求复杂的DTO。
使用CQRS你能避免这些预测。相反，它是可以引入一个新的DTO的投影方式。您可以绕过域模型和DTO的直接使用读出层从数据存储。当一个应用程序请求数据，这可能是由一个单向的调用read层返回单个包含所有需要的数据DTO。
CQRS
Pattern: Command Query Responsibility Segregation (CQRS)
领域驱动设计(DDD:Domain-Driven Design)
六边形架构
允许应用程序都是由用户，程序，自动化测试或批处理脚本驱动的，在事件驱动和数据库环境下被开发和隔离测试。一个事件从外面世界到达一个端口，特定技术的适配器将其转换成可用的程序调用或消息，并将其传递给应用程序。该应用程序是可以无需了解输入设备的性质(调用者是哪个)。当应用程序有结果需要发出时，它会通过一个端口适配器发送它，这个适配器会创建接收技术（人类或自动）所需的相应信号。该应用程序与在它各方面的适配器形成语义良性互动，但是实际上不知道适配器的另一端的谁在处理任务。
这个有点懵逼！