通用设计原则
1 关注点分离
分离关注点是开发时的指导原则。它的意思就是说尽量按照功能种类进行模块化划分。每个工功能模块功能独立，这就是关注点分离原则。例如，一个应用程序，通过业务逻辑需要将业务中某些项通过可自定义的格式在页面显著标识出来。那么业务逻辑业务的选择与格式化显示就是两个独立的关注点，按照关注点分离的原则，两者需要功能分离。
这种分离有助于确保业务模型易于测试，并且可以在不与底层实现细节紧密耦合的情况下进行演进。关注点分离是在应用程序架构中使用层的一个关键考虑因素。
总之，一般来说关注点分离就是按功能种类，模块能够细化尽量细化。
2 封装
应用程序的不同部分应该使用封装来将它们与应用程序的其他部分隔离开来。只要不违反外部契约，应用程序组件和层应该能够在不破坏协作者的情况下调整其内部实现。恰当地使用封装有助于在应用程序设计中实现松耦合和模块化，因为只要保持相同的接口，对象和包就可以被替代的实现代替。
在类中，封装是通过限制外部访问类的内部状态来实现的。如果外部参与者想要操作对象的状态，它应该通过定义良好的函数（或属性设置器）来操作，而不是直接访问对象的私有状态。同样，应用程序组件和应用程序本身应该公开定义良好的接口供其协作者使用，而不是允许直接修改它们的状态。这使得应用程序的内部设计能够随着时间的推移而发展，而不必担心这样做会破坏协作者，只要公共契约得到维护。
3 依赖反转
应用程序中依赖关系的方向应该是朝着依赖抽象的方向，而不是面向实现细节的方向。比较随意的大多数应用程序都是这样编写的，即编译时依赖项沿着运行时执行的方向流动，从而生成一个直接的依赖关系图。也就是说，如果模块A调用模块B中的函数，模块B调用模块C中的函数，那么在编译时A将依赖于B，而B又依赖于C，如下图所示。
应用依赖性反转原理是B实现的某个抽象接口，A调用B所实现的接口方法，使得A可以在运行时调用B，但B在编译时依赖于由A控制的接口（因此，反转典型的编译时依赖关系）。在运行时，程序执行的流程保持不变，但是接口的引入意味着可以轻松地插入这些接口的不同实现。（本来第一幅图A是依赖于B所实现的方法的，箭头都是往下的，到了第二幅图，B的实现是依赖于接口B（接口B是由A提供的），这根箭头朝上了，所以叫反转）
依赖倒置是构建松散耦合应用程序的关键部分，因为实现细节可以编写为依赖和实现更高级别的抽象，而不是相反。由此产生的应用程序更易于测试、模块化和可维护。依赖注入的实践是通过遵循依赖反转原理来实现的。
4 显式依赖关系
显示依赖关系就是说类无法独立完成某个功能，依赖别的类的时候，那么一般需要在构造函数入口参数上显示的给出依赖参数。这样子便于测试。
5 单一职责
6 避免重复造轮子
同一个功能的轮子，不要重复造，如果确实是同一个轮子，合并成一个轮子，便于维护。
7 持久化无感
如果涉及到持久化（数据库读写、文件读写这种），数据功能代码尽量不依赖于具体的持久化方式。还没有搞太明白。????
8 有界上下文
这个还不是特别明白。????