通用设计原则
分离关注点
构建应用程序应该将核心业务行为与基础结构及用户界面逻辑分开，理想情况下业务规则和逻辑应单独位于一个项目中，且不依赖于应用程序中的其他项目。封装
应用程序中的不同部分应该通过封装与应用程序中的其他部分隔离开。只要不违反外部协定，应用程序组件和层能在不中断其他协作者情况下调整其内部实现。正确的封装有助于应用程序中实现松散耦合及模块化。
应用程序本身应公开明确定义的接口供协作者使用，而非让协作者直接修改其状态。这样才能不断改进内部程序设计，而无需担心中断协作者。
依赖关系反转
应用中的依赖关系方向应该是抽象的方向，而不是实现详细的方向。应用关系依赖反转后，A可以调用实现B的抽象方法，让A可以在运行时调用B，而B在编译时依赖于A控制的接口。依赖项反转是生成松散耦合应用程序的关键一环。因为可以实现详细信息编写为依赖并实现更高级别的抽象，而不是相反。
显式依赖关系
方法和类应该显示要求正常工作所需的任何协作对象。通过类构造函数，类可以标识其实现有效状态和正常工作所需内容。
单一责任
单一职责适用于面向对象设计，也可以视作分离关注点的体系机构原则。他指出对象应该只有一个职责，并且只能因为一个原因更改对象。将此原则应用到应用程序体系结构和逻辑终结点时，你将获得微服务。微服务应该具有单一职责，一般而言，如果需要扩展系统行为，最好通过添加其他微服务来实现。
不要自我重复
应用程序应该避免在多个地方指定与特定概念的行为，因为这样容易导致出错。请将逻辑封装在编程构造中，而不要重复该逻辑。让构造成为针对此行为的单一权限。
持久性无感知
持久无感知（PI）指需要保持不变的类型，但其代码不受所选择的持久性技术（例如SqlServer换MySql）的影响。违反此原则的示例：
- 必须的基类。
- 必须的接口实现。
- 负责其保证自身的类（例如活动记录模式）。
- 所需的无参数构造函数。
- 需要virtual关键字的属性。
- 特定于必须持久化的必须特性。
有界上下文
有界上下文是领域驱动的中心模式。可以将大型程序分解为独立的概念模块，通过这种方式来解决复杂性问题。理想情况下每个有界限的上下文都应该能够为其其中的概念自由选择名称，并对自己的持久性储存具有独占访问权。