微软的软件架构设计原则

构架原则

微软官网有一个篇短文专门讲解Web架构设计原则site . 且把它翻译一下, 品位下.

常见的设计原则

Separation of Concerns

Separation of Concerns字面翻译是关注点的分离, 其实很多情况下, 我们的架构设计都遵循这个原则. 这个原则指出软件应该根据工作类型的不同被分离. 这个原则是Edsger W. Dijkstra在论文On the role of scientific thought提出的. 原则上将一个计算机程序分割成不同模块的程序, 分割一个程序的不同关注点,一个模块只关心一个点. 同时业务行为设计也要和基础架构, UI展示层分离. 这样业务逻辑的分离可以保证业务可以被单独测试和进化, 而不是和其他实现紧密耦合.

Encapsulation 封装

应用的不同部分需要使用封装来隔离, 而通过外部接口保持直接的协作不受内部实现的改变的影响.

Dependency inversion 依赖反转

• 高层次的模块不要依赖于低层次的模块，都应该依赖于抽象(接口)。
• 抽象(接口)不应该依赖于具体，而具体要依赖于抽象。
  
  普通类依赖关系是直接依赖, 如下图:
  
  但是为了系统松耦合, 可测试, 模块化和可维护, 使用依赖反转原则将类的依赖反转, 使原本依赖类B的类A依赖自己控制的接口A, 而类B也依赖接口A. 这样就实现了依赖反转. 下图比微软官网更加清晰:  这样的实现, 虽然在代码实现时需要多余的实现, 但是在运行时它的依赖关系并没有改变. 依赖反转原则也为依赖注入提供了可能.

Explicit dependencies 显式依赖

这条原则也很明显

Single responsibility 单一责任

单一责任是针对面向对象设计, 对象只有一个责任, 也只有一个理由做改变. 也就是说只有当对象的责任发生改变时, 对象的才能被改变. 有了这个原则, 当一些行为需要新的实现时, 就应是写新的类, 而不是在原有的类上增加代码. 采用这个原则, 我们的应用也可以往微服务的方向发展.

Don’t repeat youself (DRY)

“干”的原则时很常见. 保持只有一个true source很重要.

Persistence ignorance 持久化无关

代码和持久化技术无关.

Bounded contexts

有界上下文是领域驱动设计的核心模式. 它们可以将大型应用程序或组织分解为独立的概念模块，通过这种方式来解决复杂性问题。 每个概念模块表示各自独立的上下文（因此有界），并且可以独立改进。 理想情况下，每个有界上下文都应该能够为其中的概念自由选择它自己的名称，并对其自己的持久性存储具有独占访问权限。