架构简洁之道

1 UML学习

业务建模是从组织的角度来定位系统应该提供的价值。业务执行者是在组织之外和组织交互的人群或组织。在组织内部的是业务工人，它是可以被替换的，比如可以被业务实体替换。业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了。我们画好现状的业务序列图，然后把待开发的系统作为一个新的业务实体空降到序列图中，寻找改进点，得到该业务实体的责任，就可以直接映射到待开发系统的用例。

业务用例是指业务执行者希望通过和组织交互达到的，且组织能提供的价值。以商业银行为例，储户的用例如下：

如果穿越回三百年前，上图的用例图仍然适用。业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。三百年前，银行要实现“储户→存款”的用例，需要许多人肉系统（业务工人）一起协作，现在则变成了少数人肉系统（业务工人）和许多电脑系统（业务实体）之间的协作。 

 2 面向对象学习

封装
继承
多态

3 架构简洁之道笔记

依赖倒置：低层的实现细节依赖于高层的抽象。高层规定了接口？如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型/抽象接口，而非具体实现。创建对象都存在源代码级的依赖。因此，选用抽象工厂这个设计模式。
不要在具体实现类上创建衍生类。

面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件架构师可以构建出某种插件式架构，让高层策略性组件与底层实现性组件相分离，底层组件可以被编译成插件，实现独立于高层组件的开发和部署。

SOLID原则的主要作用就是告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。

开闭原则：如果A组件不想被B组件上发生的修改所影响，那么就应该让B组件依赖于A组件。
软件系统不应该依赖其不直接使用的组件。

Liskov原则：实现接口的类应该具有替换性。

组件结构图不可能自上而下被设计出来。它必须随着软件系统的变化而变化。稳定抽象原则要求稳定的组件同时应该是抽象的，这样它的稳定性就不会影响到扩展性；另一个方面，该原则也要去一个不稳定的组件应该包含具体的实现代码。因此，一个组件要想成为稳定组件，它就应该由接口和抽象类组成，以便将来做扩展。

架构设计目标：1）保留可选项；2）按层解耦和按用例解耦；3）支持多团队开发和灵活部署。倾向于将系统的解耦推行到某种一旦有需要就可以随时转变为服务的程度即可，让整个程序尽量长时间地保持单体结构。一个设计良好的架构应该能允许一个系统从单体结构开始，以单一文件的形式部署，然后逐渐成长为一组相互独立的可部署单元，甚至是独立的服务或者微服务。最后还能随着情况的变化，允许系统逐渐回退到单体结构。

系统的核心业务逻辑必须和其他组件隔离，保持独立，而这些其他组件要么是可以去掉的，要么是有多种实现的。

业务实体实际上就是计算机系统中的一种对象，这种对象包含了一系列用于操作关键数据的业务逻辑。这些实体对象要么直接包含关键业务数据，要么可以很容易的访问这些数据。业务实体的接口层则是由那些实现关键业务逻辑、操作关键业务数据的函数组成的。业务实体这个概念只要求我们将关键业务数据和关键业务逻辑绑定在一个独立的软件模块内。用例描述的是某种特定应用情景下的业务逻辑，并非业务实体中的关键业务逻辑。用例中包含了对如何调用业务实体中的关键业务逻辑的定义。简而言之，用例控制着业务实体之间的交互方式。业务实体是一个可以适用于多个应用情景的一般化概念。

良好的架构设计应该围绕用例展开。

 内层圆的代码不应该牵涉外层圆中的代码，尤其是内层圆中的代码不应该引用外层圆中代码所声明的名字，包括函数、类、变量以及一切其他命名实体。

Ivar Jacobson Object oriented software engineering, a use case driven approach

如果框架要求我们根据它们的基类创建派生类，就请不要这样做！我们可以创造一些代理类，同时把这些代理类当做业务逻辑的插件来管理。

系统划分成视图、展示器、交互器以及控制器组件，同时按照对应角色进行分组。