《架构整洁之道》之独立性

一个良好的软件架构必须支持以下几点。

• 系统的用例与正常运行。
• 系统的维护。
• 系统的开发。
• 系统的部署。

一、用例

一个系统的架构必须能支持其自身的设计意图。也就是说，如果某系统是一个购物车应用，那么该系统的架构就必须非常直观地支持这类应用可能会涉及的所有用例。事实上，这本来就是架构师们首先要关注的问题，也是架构设计过程中的首要工作。软件的架构必须为其用例提供支持。

一个设计良好的架构在行为上对系统最重要的作用就是明确和显式地反映系统设计意图的行为，使其在架构层面上可见。

二、运行

架构在支持系统运行方面扮演着更实际的角色。如果某个系统每秒要处理100000个用户，该系统的架构就必须能支持这种级别的吞吐量和响应时间。同样的，如果某个系统要在毫秒级的时间内完成对大数据仓库的查询，那么该系统的架构也必须能支持这类操作。

三、开发

任何一个组织在设计系统时，往往都会复制出一个与该组织内沟通结构相同的系统-康威定律。

一个由多个不同目标的团队协作开发的系统必须具有相应的软件架构。这样，这些团队才可以各自独立地完成工作，不会彼此干扰。这就需要恰当地将系统切分为一系列隔离良好、可独立开发的组件。然后才能将这些组件分配给不同的团队，各自独立开发。

四、部署

一个系统的架构在其部署的便捷性方面起到的作用也是非常大的。设计目标一定是实现”立刻部署”。一个设计良好的架构通常不会依赖于成堆的脚本与配置文件，也不需要用户手动创建一堆”有严格要求”的目录与文件。总而言之，一个设计良好的软件架构可以让系统在构建完成之后立刻就能部署。

五、保留可选项

一个设计良好的架构应该通过保留可选项的方式，让系统在任何情况下都能方便地做出必要的变更。

六、按层解耦

一个系统可以被解耦成若干个水平分层-UI界面、应用独有的业务逻辑、领域普适的业务逻辑、数据库等。

七、用例解耦

如果我们按照变更原因的不同对系统进行解耦，就可以持续地向系统内添加新的用例，而不会影响旧有的用例。如果我们同时对支持这些用例的UI和数据库也进行了分组，那么每个用例使用的就是不同面向的UI与数据库，因此增加新用例就更不太可能会影响旧有的用例了。

八、解耦的模式

SOA(面向服务架构)或微服务可以作为解耦模式的可选项之一。

九、开发的独立性

只要系统按照其水平分层和用例进行了恰当的解耦，整个系统的架构就可以支持多团队开发，不管团队组织形式是分功能开发、分组件开发、分层开发，还是按照别的什么变量分工都可以。

十、部署的独立性

按用例和水平分层的解耦会给系统的部署带来极大的灵活性。如果解耦工作做得好，我们甚至可以在系统运行过程中热切换其各个分层实现和具体用例。

十一、重复

架构师害怕重复，但重复在软件行业里一般来说是一件坏事。有些是真正的重复，有些仅仅是表面的重复。我们所要解决的是真正的重复。

十二、再谈解耦模式

• 源码层次:我们可以控制源代码模块之间的依赖关系，以此来实现一个模块的变更不会导致其他模式也需要变更或重新编译(例如Ruby Gem)。
• 部署层次:我们可以控制部署单元(譬如jar文件、DLL、共享库等)之间的依赖关系，以此来实现一个模块的变更不会导致其他模式的重新构建和部署。
• 服务层次:我们可以将组件间的依赖关系降低到数据结构级别，然后仅通过网络数据包来进行通信。

一个设计良好的架构应该能允许一个系统从单体结构开始，以单一文件的形式部署，然后逐渐成长为一组相互独立的可部署单元，甚至是独立的服务或者微服务。

一个设计良好的架构应该能保护系统的大部分源码不受变更影响。对整个系统来说，解耦模式也应该是一个可选项。我们再进行大型部署时可以采用一种模式，而在进行小型部署时则可以采用另一种模式。