(微信扫码咨询)
架构的定义
直销系统软件架构是在交付基本功能的基础上，使系统易于开发、部署、运行和维护，以支持软件系统的生命周期。在架构设计中，尽可能长地保留尽可能多的选择。
直销系统软件架构师必须是程序员，一线程序员，能力最强的一线程序员。当然，代码不一定是最多的。
为什么要提到编程范式？
结构化编程是对程序控制权直接转移的限制(限制)goto）；
面向对象编程是对程序控制权间接转移的限制(限制函数指针)；
函数编程是对程序中赋值操作的限制(限制变量多次赋值，避免临界区竞争问题)。
与软件生成之初相比，每个范式都是为了限制某种编写代码的方式，没有一种范式是为了增加新的能力。
编程范式与架构有关吗？当然，例如，面向对象的多态化是跨越架构边界的手段，函数编程是规范和限制数据存储位置和访问权限的手段，结构化编程是实现每个模块算法的基础。这与直销系统软件架构的三个重点不谋而合：功能、组件独立性和数据管理。
也就是说，编程范式是一种架构约束。
SOLID扩展到架构维度也适用于架构维度
SRP：每个软件模块都有，只有一个理由被改变；
OCP：软件设计必须允许新代码改变系统的行为，而不仅仅是修改原始代码；
LSP：如果你想用可替代的组件构建软件系统，那么这些组件必须遵守同样的协议，以便这些组件可以相互替换；
ISP：本设计原则主要警告软件设计师在设计中避免不必要的依赖；
DIP：该设计原则指出，高层战略代码不应依赖于实现底部细节的代码。相反，实现底部细节的代码应依赖于高层战略代码。DIP这将是这本书的核心思想。
组件
组件聚合
组件是软件的部署单元，是整个软件系统在部署过程中能够独立完成部署的最小实体。java的jar，C的so等，或者python一组源文件。动态链接技术使组件插件架构成为软件构建的常见形式。
那么，哪些内容应该属于同一组件呢？从几个原则开始：
REP：重用/发布等价原则
软件重用的最小粒度应等于其发布的最小粒度。也就是说，同一组件中的类和模块应该可以同时发布。这意味着它们共享相同的版本号和版本跟踪，并包含在相同的发布文档中，这对组件的作者和用户都应该有意义。
CCP：共同闭包原则
我们应该并且只应该将同时修改并为同一目的修改的类别放入同一组件中。
这实际上是在组件层面SRP原则。正如SRP原则中提到的一类不应同时有多个变化原因。CCP原则还认为，一个组件不应同时有多个变化原因。
CRP：共同复用原则
不要强迫一个组件的用户依赖他们不需要的东西。ISP这个原则是相似的。另一方面，当我们决定依赖某个组件时，我们组件中的每一类。
权衡和取舍
事实上，上述三个原则存在矛盾。REP和CCP是粘合原理，可能使组件变大，CRP原则是排除性原则，可能会使组件变小。架构师应该清楚，这三个原则可能不能同时考虑，需要权衡。
组件张力图
不同的项目特点和项目阶段也有不同的关注点。一般来说，在项目的早期阶段，可能会牺牲一些重用性，而在项目的后期，随着其他项目对自身依赖的增加，我们需要更加关注REP原则。
因此，组件的划分原则可能是一个需要不断变化的过程，这需要经验丰富的架构师根据项目特定阶段的主要矛盾进行实时调整。这也要求直销系统的软件架构设计具有随时可调的灵活性。
组件耦合
ADP：无依赖环原则
最理想的情况是组件之间没有依赖，但这是不可能的，即使可以，这样的组件也是毫无意义的。另一方面，我们应该承认依赖存在的必要性，我们需要依赖，但组件依赖关系不应该出现。
如果有循环依赖，任何组件的变化都必然导致依赖环中所有组件的变化。这与我们所期望的至少依赖不一致。
循环依赖
上图中，A变化必然导致B和B和C重新编译，同样，任何组件的变化都必然导致另外两个组件的重新编译，甚至重新测试。
解决循环依赖的两种方法：
1.应用DIP原则：
形成依赖性倒置
2.增加一个新的组件(可视为适配器)
新增适配器组件
通过解除循环依赖，B变化不会导致其他几个组件的变化。
以上两种方法解决了A和AB相互依赖。同样，这种方法也可以应用于A和A，C，B和C之间。但随着依赖关系的解除，组件数量也在增加，组件的管理成本也会增加，这需要架构师来权衡。
SDP：稳定依赖原则
依赖是不可避免的，但依赖关系必须朝着更稳定的方向发展。
这个原则太明显了，不能再解释了。需要注意的是，如果组件之间不符合这些原则，它可以通过一些方法来满足这个原则，是的，它是DIP。
SAP：稳定抽象原则
组件的抽象程度应与其稳定性一致。
我们希望所依赖的组件具有稳定的特性，而稳定的组件通常会被许多组件所依赖。这样，稳定的组件就不应该经常被修改，这限制了组件的灵活性。如何调和这个矛盾？是的，它是抽象的。稳定的组件应该是抽象的，这样OCP原则既能满足现有内容的不变性，又能满足新修改的可扩展性。
小结：
组件关系不能在项目开始时确定，它是一个随着项目的不断扩展和演变而进行的过程，这证实了自上而下设计的不可靠性。此外，组件依赖结构图不用于描述应用程序功能单元，更像是应用程序在构建和维护方面的地图。
直销系统软件架构图
自敏捷以来，代码设计的趋势使人们完全放弃了设计图纸，这实际上是一种极端。仔细观察敏捷大师，他们不是没有架构图，而是不再纠结于细节。与此同时，架构图的形式也不再严格局限于UML形式。
因此：
要有架构图；
要有框架，还要有线，表明关系；
框中的描述必须具有商业意义。
架构设计的核心技术：依靠倒置和战略模式
所有跨架构边界的处理都可以考虑依赖倒置和战略模式。
依赖倒置
这里的依赖倒置，为了达到倒置的目的，可以使用更先进的实现技术，本文的精辟解释。在设计组件时，我们必须注意边界和界面定义的所有权。它代表了依赖反转原则在更大架构层面上的应用。
更大程度上依赖倒置
这张图是整洁架构右下角的图
首先，我们需要识别自己的核心资产（核心领域），所以这个核心领域是所有其他部分都需要崇拜的，也就是说，所有其他部分都需要依赖它，而不是反过来。
这里所谓的核心域是相对的，UI是用户的非核心域，而是用户的非核心域UI开发团队是核心领域。此外，它不能基于代码的大小，也不能基于所涵盖的功能。唯一的划分依据应该是你维护的代码（或为你赚钱的代码），这是你应该保护的核心。
整洁架构同心圆
上图中的同心圆分别代表了系统软件的不同层次。通常离中心越近，软件层次就越高。基本上，外圆代表机制，内圆代表策略。
上述同心圆非常相似MVC模式，其实MVC核心思想也是隔离稳定的核心业务和多变的外部表现。我们可能低估了它。MVC的威力。
贯穿整个架构设计的规则：源代码中的依赖关系必须指向同心圆的内层，即从底层机制指向高层策略。
具体到代码实现，即内层应定义接口，让外层实现（通常使用接口适配器层），我们不应该让外层的任何变化影响内层。
架构设
