架构设计是高内聚、低耦合的体现；由高内聚、低耦合扩展出六大设计原则，由设计原则归纳出常用设计模式；设计模型、工具构建起架构骨架、设计原则来指导和考量架构的设计合理性。

UML 是架构设计的通用语言、工具，UML 通过提供不同的视图来设计软件，例如：部署图、组件图、时序图、类图、活动图、状态图、用例图。

设计原则

1、开闭原则

对扩展开放、对修改关闭；该原则是设计原则的核心原则。修改关闭通过面向对象的封装特性实现；对扩展开放通过面向对象的继承、组合、多态；扩展往往通过组合、多态实现；继承相对于组合较重，也存在破坏封装性的可能。

2、依赖倒置原则

依赖抽象，调用方（使用方）定义规则（接口），调用方不依赖于被调用方，接口由调用方定义；有时候也被称为好莱坞原则。

架构设计中使用该原则较多，由架构定义流程、定义接口、定义扩展点。

架构（框架）定义流程、扩展点的方式可以通过接口或 SPI、注解以及协议来实现。

3、里氏替换原则

存在两个对象 A 和 B，A 继承 B，所有使用 B 的地方，都可以使用 A 替换即是里氏替换原则。面向对象的继承是里氏替换原则的实现方式，但不是所有继承都遵循里氏替换原则。里氏替换强调的是替换；

即一个接口的多个实现，是否也可以称为里氏替换原则呢？

4、单一职责原则

一个类只承担一个职责。单一职责主要在于对职责的识别和划分，不同的视角观察，划分的职责也不一样。职责可大可小

什么是职责呢？一个职责是一个变化的原因。

职责可以分成职和责两字，职是职位、责是责任；即在设计时为该类定义什么职，就定义了类的责。

职责的定义也边界的定义，如何定义边界呢？

如何去考量职责划分是否合理呢？可以从引起变化原因、性质来考量，或者通过开闭原则来识别。

5、接口隔离原则

6、最小依赖原则（迪米特原则）

代码“臭”味

1、僵化

很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的改动。

• 如果单一的改动会导致依赖关系的模块中的连锁改动，那么设计就是僵化的，必须要改动的

模块越多，设计就越僵化。

系统与系统、模块与模块，函数与函数之间耦合太强，不易复用、修改，造成一个修改涉及范围大，造成连锁修改。

造成僵化的原因可能有哪些？

2、脆弱

对系统的改动会导致系统中和改动的地方无关的许多地方出现问题。

• 出现新问题的地方与改动的地方没有概念上的关联。要修正这些问题又会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样。

对系统的修改，容易造成和改动无关功能的出现问题；修改系统一个功能，；对系统功能的扩展，需要通过修改原有代码来实现，不能通过扩展实现。

造成脆弱的原因，可能有哪些？

3、牢固

设计中包含了对其他系统有用的部分，而把这些部分从系统中分离出来所需的努力和风险是巨大的。

4、晦涩

很难阅读、理解。没有很好的表现出意图。

解决晦涩的问题：名称含义清晰、编写必要注释、编写必要设计图

5、过度（复杂）

设计中包含有不具任何直接好处的基础结构。如果设计中包含有当前没有用的组成部分，他就含有不必要的复杂性。当开发人员预测需求的变化，并在软件中放置了处理那些潜在变化的代码时，常常会出现这种情况。

如果设计中包含有当前没有用的组成部分，他就含有不必要的复杂性。当开发人员预测需求

的变化，并在软件中放置了处理那些潜在变化的代码时，常常会出现这种情况。

如何识别一个设计是否是过度设计呢？什么样的设计是合理的呢？

6、散落（重复）

设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。一个功能散落到各个服务中；重复代码散落到各个代码中。

flower 响应式框架

1、基于 Akka 的实现

2、扩展 akka 的 actor 的实现 FlowerActor

3、扩展构建请求流