本文是通过学习李运华老师的《从0开始学架构》课程的随笔
现在自己对架构云里雾里的感觉，结合工作中的实践，学习与总结，慢慢的，会有质的提升的。
架构设计三原则：适合原则、简单原则、演化原则
适合原则（合适优于业界领先）
将军难打无兵之战
罗马不是一天建成的
冰山下面才是关键
在项目管理中，项目启动、规划、执行、监控、验收的整个过程，我们需要整个过程中合理评估和知晓我们所拥有的资源，人力、物力、财力等资源，知晓并合理安排使用，那么输入和产出比应该是在可控范围内，风险也应该尽可能的会在可预知风险中。
架构设计也是如此，如今技术发展很快，各种架构框架层出不穷，不一定先进的就是我们应该选择的，不是全而大的就是我们团队需要的。
架构是需要资源支撑的(我们需要考虑人力、物力、财力等)；架构是需要不断实践趟坑的，稳扎稳打通过实践不断积累演进；架构是需要业务支持的（量变会引起质变），当业务不断增长时，它会逼着你去做架构的调整及演化。
简单原则（简单优于复杂）
“复杂”在制造领域代表先进，在建筑领域代表领先，但在软件领域代表“问题”
复杂度的体现：
1、结构复杂性
(1)、2个、3个、N个组件，组件越多，就越有可能某个组件故障从而导致系统故障；
(2)、某个组件的改动，会影响关联的所有组件；
(3)、定位一个复杂系统中的问题总是比简单系统更加困难；
2、逻辑复杂性
单个组件承担了太多的功能
逻辑复杂度会导致软件工程的每个环节都有问题，如迭代、分支……。
软件设计产出投入使用后，需要不断的迭代变更(新需求等)、需要不断的修改。
如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。
演化原则（演化优于一步到位）
对于建筑来说，永恒是主题，对于软件来说，变化是主题。
软件架构需要根据业务发展不断变化。软件架构设计类似于大自然设计一个生物，通过演化让生物适应环境，逐步变得更加强大。
起初设计出来需要满足当时的业务需要→需要不断在世纪应用过程中迭代，保留优秀的设计，修复不足和缺陷，改正错误的设计、去除无用的设计→业务发生变化时，需要对架构进行扩展、重构甚至重写，但有价值的经验教训、逻辑设计等却可以在新架构汇总延续。