软件设计-体系结构原则

通用设计原则

构建应用程序应该将 核心业务行为与 基础结构及 用户界面逻辑分开，理想情况下 业务规则和逻辑应单独位于一个项目中，且 不依赖于应用程序中的其他项目。

应用程序中的不同部分应该通过封装与应用程序中的其他部分隔离开。只要不违反外部协定，应用程序组件和层能在 不中断其他协作者情况下 调整其内部实现。正确的封装有助于应用程序中实现 松散耦合及 模块化。

应用程序本身应公 开明确定义的接口供协作者使用， 而非让协作者直接修改其状态。这样才能不断改进内部程序设计，而无需担心中断协作者。

应用中的依赖关系方向应该是 抽象的方向，而不是实现详细的方向。应用关系依赖反转后，A可以调用实现B的抽象方法，让A可以在运行时调用B，而B在编译时依赖于A控制的接口。

依赖项反转是生成松散耦合应用程序的关键一环。因为可以 实现详细信息编写为依赖并实现更高级别的抽象，而不是相反。

方法和类应该显示要求正常工作所需的任何协作对象。通过 类构造函数，类可以 标识其实现有效状态和 正常工作所需内容。

单一职责适用于面向对象设计，也可以视作分离关注点的体系机构原则。他指出 对象应该只有一个职责，并且 只能因为一个原因更改对象。

将此原则 应用到应用程序体系结构和 逻辑终结点时，你将 获得微服务。微服务应该具有单一职责，一般而言，如果需 要扩展系统行为，最好 通过添加其他微服务来实现。

应用程序应该 避免在多个地方指定与特定概念的行为，因为这样容易导致出错。请 将逻辑封装在编程构造中，而不要重复该逻辑。让构造成为针对此行为的单一权限。

持久无感知（PI）指需要保持不变的类型，但其代码不受所选择的持久性技术（例如SqlServer换MySql）的影响。

违反此原则的示例：

有界上下文是 领域驱动的中心模式。可以 将大型程序分解为独立的概念模块，通过这种方式来解决复杂性问题。理想情况下 每个有界限的上下文都应该能够为其其中的概念自由选择名称，并 对自己的持久性储存具有独占访问权。