范畴驱动设计的战略中心即是将问题域与运用架构相剥离，将事务语义显现化，把原先晦涩难明的事务算法逻辑，经过范畴对象（Domain Object），一致言语（Ubiquitous Language）转化为范畴概念明晰的显性化表达出来。
1、一致言语，软件的开发人员/运用人员都运用同一套言语，即对某个概念，名词的认知是一致的，树立明晰的事务模型，构成一致的事务语义。将模型作为言语的支柱。确保团队在内部的一切沟通中，代码中，画图，写东西，特别是说话的时候都要运用这种言语。例如账号，转账，透支策略，这些都是非常重要的范畴概念，如果这些命名都和咱们日常讨论以及 PRD 中的描绘保持一致，将会极大提高代码的可读性，削减认知本钱。。比如不再会有人在会议中对“工单”、“审阅单”、“表单”而重复确认含义了，DDD 的模型树立不会被 DB 所绑架。
2、面向范畴，事务语义显性化，以范畴去思考问题，而不是模块。将隐式的事务逻辑从一推 if-else 里边抽取出来，用通用言语去命名、去写代码、去扩展，让其变成显现概念；许多重要的事务概念，按照事务脚本的写法，其含义彻底淹没在代码逻辑中没有突显出来。
3、责任区分，根据实践事务合理区分模型，模型之间依靠结构和边界愈加明晰，避免了紊乱的依靠关系，从而添加可读性、可维护性；单一责任，模型只重视自身的本职工作，避免“越权”而导致紊乱的调用关系。经过建模，更好的表达实际国际中的复杂事务，跟着时间的发展，不断添加体系对实践事务的沉积，也将更好的经过明晰的代码描绘事务逻辑，模型的内聚添加了体系的高度模块化，提高代码的可重用性，比照传统三层形式中，很有或许大量重复的功用散落在各个 Service 内部。
如若转载，请注明出处：开源字节 sourcebyte.cn/article/227…
