什么是你的领域模型?


从技术角度来看,我认为DDD项目只不过是划定一个清晰且受保护的领域。虽然我在处理大量遗留代码,但我发现常见的DDD错误是无法准确识别领域内的内容以及外部的内容。

您的数据模型不是您的域模型
将数据模型用作领域模型是一个非常常见的错误。我认为ORMCRUD对这种误解负有部分责任。数据模型是针对数据存储优化的模型的表示。

使用ORM构建的模型对象不会使其成为领域模型。它仍然是一种数据模型,它仍然针对数据存储进行了优化。它只是不再是sql表,仅此而已。

数据模型负责存储数据,而域模型负责处理业务逻辑。只有在数据模型周围没有业务逻辑时,才能将应用程序视为CRUD。即使在这种(罕见)情况下,您的数据模型也不是您的域模型。它只是意味着,由于不涉及业务逻辑,我们不需要任何抽象来管理它,因此我们没有领域模型。

您的视图模型不是您的域模型
另一个常见错误是在数据模型和视图之间只添加一个层。这个层在不同的模式和语言中有不同的名称(Presenter,Controller,ViewModel ...... 等各种MVC中P/C/VM),但想法是一样的:使用代码抽象视图。

错误是我们认为这是添加业务逻辑的地方。但是这些层已经有负责抽象视图,我们不想添加任何其他责任。


您的数据模型不应通知您的视图
当我发现一个模型对象负责在某些数据发生变化时通知视图时(通常使用数据绑定),我发疯了。只是因为它的字面意思是个数据或领域对象,也有责任管理数据的显示方式。

像往常一样,分离关注。

您的领域模型应该(几乎)没有任何依赖

领域模型是一组类或函数,在领域层中分组,包含所有业务逻辑。该层完全没有基础设施。它应该是业务的纯粹抽象。

如果我们改变渲染软件的方式,领域模型仍然有效。如果我们更改数据存储,领域模型仍然有效。如果我们决定停止使用我们最喜欢的Framework,域模型仍然有效。


领域模型只依赖于一件事:业务。