1、引言
“以铜为镜，可以正衣冠；以古为镜，可以知兴替；以人为镜，可以明得失。”，知道历史，明白为什么会出现这些问题，历史上又是如何解决这些问题，现在还存在哪些问题。在学习某个知识点的时候也是如此。
在学习的路上总是会让人盲目，大家都说好，那就是好，套以现成，拿以卖弄，问不知所以然，贻笑大方。学习需要深入，学习一个技术，要知道技术的历史交替、兴衰胜败，然后分析，理解，总结，完善。
2、发展历程
上图由上而下的顺序就是软件架构的发展历程。
- 结构化
几乎每个程序员最初学习变成语言的时候写的都是结构化代码
public class Demo {
public static void main(String[] args) {
int a = 1;
String b = "hello";
System.out.println(b);
for (int i = 0; i < 3; i++) {
if (i == a) {
System.out.println(b);
}
}
}
}
唯一入口main方法，自上而下顺序执行，定义变量，循环，判断，得到结果，结束。
结构化架构就是如此，分为多个模块互相独立，其中一个是入口模块(main),其中操作就是其他子模块(方法),入口模块调用子模块的方式运行。
但是在日益复杂的需求下，这种架构很难满足，但是并非被淘汰，因为结构简单，并且独立，所以能很好的与硬件所结合，单片机程序非常适合这种思想去写代码。
- 面向对象
结构化设计又被称为面向过程，只注重运行过程的程序，面向对象则颠覆了这种想法，对象可以理解为“人”，举个例子，面向过程就是A拿起苹果，面向对象就是不去考虑谁拿起了什么，而是考虑这里面有几个对象(人、苹果两个对象),然后再去实现人拿起苹果这个动作。
面向对象并不是单纯的封装、继承、多态，而是在分析需求的时候，优先想到对象，在联系对象去构想动作。提取出重复的动作为方法，不管是谁拿起了什么，只需要调用拿起这个方法即可。
相比起结构化设计，面向对象无疑是在业务分析和简洁代码上都有很大的优势，但是缺点也很明显就是性能差(这是相对结构化程序性能差),占用大量的内存空间,很多时候使用一个方法但是却要去创建一整个类。
- 设计模式
设计模式其实本质上还是面向对象，只是将面向对象用的更加灵活多变，更加针对性，同时也尽可能弥补一些面向对象所存在的缺点，可以说是对面向对象的一种使用方法，理论上可以设计一个完全弥补面向对象缺点的设计模式，但是理想很丰满，现实很骨感，正确的方式就是针对特定的场合使用合适的设计模式。
- DDD
我认为DDD是将面向对象的思想扩大化，如果把类理解为领域，那么划分领域就是划分类，领域种的子领域就是方法，限界上下文就是类与类、方法与方法之间的关系和界限。
但是DDD提出的一点确实与传统架构有着很大区别，那就是在分析需求，划分领域时，传统方案是由架构师、技术经理一起分析后，再分派安排到各组各人任务，而DDD提倡的是全员参与讨论划分领域，统一建模语言。
很难说两种方式的好坏，与传统方式相比较DDD提倡的讨论法会花去更多的分析需求的时间，而且实现起来比较困难，但是对全员理解业务和整体流程更加有利。
- DCI和DSL
DCI是数据Data 场景Context 交互Interactions的简称，DCI是一种特别关注行为的模式。听上去似乎很厉害，但其实就是对DDD一种灵活变化，本质上还是DDD的领域思想。
DSL 领域特定语言（英语：domain-specific language、DSL）指的是专注于某个应用程序领域的计算机语言。DSL本质上其实就是对DCI的一次改造升级，所以追其根本还是DDD。
就我个人理解无论是DCI还是SDL都只能算是灵活改动的DDD思想，就像上面所说的设计模式与面向对象一样，设计模式再多样化，本质上还是面向对象。
- 微服务
微服务是当下热门话题，微服务就是将一个大的系统拆分成若干子系统，单独部署，单独维护。这样的好处是显而易见的，那就是系统高度解耦，互不影响，可拓展性也大大增强，需要增加新的功能，就再开发一个子系统，轻松拓展。而且每个系统都与语言无关，A子系统可以用java语言编写，B子系统可以用C#编写，语言多样化。就算那个系统崩溃了，对整体影响微乎其微，只要修复子系统即可。
所以微服务架构的好处就是独立，兄弟姐妹众多，互相独立，独立学习(升级)，生儿育女(拓展)，并且都已经独立了不是小孩子，不需要在一个大家庭中集中生活(不需要集中管理)。
但是这样造成的后果就是，如果很多兄弟姐妹遭遇困难需要帮助(负载均衡问题)，那就需要大家各自独立承担，成本非常高。如果弟弟A找姐姐B借的100元钱是姐姐B向哥哥C借的，一旦弟弟A还不起这100元的死后，姐姐B也很难还哥哥C的钱(事务回滚问题)。当父母需要把兄弟姐妹聚起来排个辈分从大到小，会因为孩子非常多而且非常分散一个个通知到而费劲经历(集中测试和运维问题)等等系列的问题需要处理。
所以微服务的成本非常高，如果在中小型项目上实施，不论实施难度，光金钱成本和时间成本还有以后的维护成本都非常高。
3、小结
总结了一大堆，其实可以发现，整个软件系统架构的演变过程其实并没有抛弃原先的东西。
无论如何，我们在写业务接口的时候依然是结构化的顺序在写。
并且无论是设计模式还是DDD依然在用继承、封装、多态。
设计模式更是对一些特定问题提出解决方案。
从每一个阶段的优缺点可以看出，在结构化时期，因为重复模块太多，随着系统越来月庞大，维护起来会越来越困难，于是面向对象应运而生。
面向对象架构实现后，面临的又是过多的浪费系统资源而导致系统性能差劲，而且系统越来越庞大以后，继承使用过多也会导致系统可读性变差。
设计模式的出现就解决了面向对象系统上很多的弊端，例如过多创建对象等等一系列问题。
无论是哪一种架构方案都是在以往的经验上不断累积的过程。就像武林大侠练武功一样，首先找一本武功练习，熟练以后研究它的本质原理，这都是遵循原理在使用，然后再根据自己的经验总结出合适自己的，适合当前使用的“武功”。
软件设计也是如此，使用它，理解它，总结它，然后在合适的地方使用自己总结出来的设计。这是一个不断完善的过程，架构其实就是开发经验的一种体现。