仅供参考,如何使用,而非建模。
免责声明:
- 建立在已经是由 DDD 良好建模过的模型基础上
- 各团队对 DDD 的解读不同,团队内的统一认知就是最好的理解
- 各项目使用不同的 DDD 实践规范,项目的规范就是最好的规范
为什么需要架构?总而言之,架构就是为了设置限制。 架构是前人基于成千上万的项目经验总结出来的一套规范,通过遵循这套规范,你就可以在未来尽可能少的去踩坑。当你所编写的代码变得庞大时,使用合适的架构就可以一定程度上避免项目的代码结构需要做出巨大调整的风险。
Deadline-Driven Design ?
Domain-Driven Design
解决复杂问题?
将实现对应到持续进化的模型。
让技术人员以及领域专家合作,以迭代方式来完善特定领域问题的概念模型。
- 业务人员和开发人员需要使用无歧义的统一语言来对话。这些语言包括对概念的统一理解和定义。
- 一个简单的方式:coding 中的关键命名 call 业务人员一起定。
- 业务相关知识的集合。
- 通俗来说,领域就是圈了些业务知识,计算机作为业务规则的自动化。
- 领域中最核心的部分。
- 换个说法,用来赚钱的那部分。
- 为了实现核心业务而不得不开发的业务所对应的相关知识的集合。
- 如果说核心域是目的,那么支撑域就是手段。
- 业界已经有成熟方案的业务,可以使用标准部件来实现,短信通知、邮件等。
- 专业的事情交给专业的人。
- 业务概念在程序中的一种表达方式。
- 一个还不错的抽象。
- 有明确边界的上下文,强调概念的一致性。
- 就是一个上下文。
- 在相同限界上下文中具有唯一标识的领域模型。
- 有身份!
- 用属性标识,任何属性的变化都视为新的值对象。
- 可装配的零件。
- 一组生命周期强一致,修改规则强关联的实体和值对象的集合,表达统一的业务意义。
- 目的强一致的组合体。
- 聚合中最核心的实体,其他的实体和值对象都从属于这个实体。
- 决策者。
- 充血还是贫血?
- 充血的主体是是什么?
- 贫的血去了哪?
- Service 的服务粒度是多大?
- Service 调度了什么?
- Application Sercive or Domain Service?
- JPA 是具体实现?还是抽象接口?
- 尝试下内存实现下数据库接口,是否真正做到屏蔽具体实现?
- 面向领域建模 or 面向数据库建模?