Domain-driven_design 中提到,实现 DDD 有三个关键要素:

我们来具体看一下在 Redux 应用中如何遵循这三要素来构建应用。

抽象并沉淀业务

知识与文档

DDD 规定了复杂的设计应该收敛到**有界上下文(bounded context)**中。通常领域的界限是由软件工程的多个方面决定的:

有界上下文, 保证了业务的一致性边界,确定了不同业务间如何通讯,它不仅能指导代码的组织与抽象方式,同时也能指导业务如何在团队中进行分配与实现,以及团队的知识如何在团队中流动。

要实现一个具体的业务需求,通常会有多种不同角色的团队成员参与其中。他们的背景、经验和水平都或多或少有所差别。

在开始需求的时候,这些不同角色的团队成员都会尝试对这个业务进行抽象与建模。但是由于个体差异,他们建立出来的模型可能会在某些地方各不匹配,这将会对项目的施展与维护造成阻碍。

所以在业务开展初期,团队成员应该对业务模型进行统一的文档化的描述,这样的文档需要满足以下几个要求:

而编写这样的文档也有一个更上层的前提: 那就是团队已经根据已有业务维护了一些用于描述抽象业务的有界上下文的文档。这些文档中定义了不同上下文的描述与边界、不同上下文的关系、上下文中的术语表以及这些术语的含义。