应在多大程度上应用DDD ?包括抽样案例

Question

我正在努力理解DDD，但是我们应该分离域的范围对我来说似乎有点棘手。

考虑几个案例：

1.实用程序

假设我有一个utility域，带有2个助手函数。

• GenerateUUID
• ValidateRegex

我是否也应该将这两个域划分为utility/uuid和utility/regex域？

2.版本控制

假设我有GenerateUUID的第一个版本实现。现在，很有可能会出现一个V2、V3等，并且有可能会发生重大变化。我是否应该将它们提取到单独的域中，如utility/uuid/v1等，这些域通过utility/uuid/common共享共同的功能？

数据库模型

假设数据库中有以下表(假设为关系表)：

• 用户
• 首选项

现在，假设我有两个操作，GetUsersWithAParticularPreference和GetPreferencesForParticularUser。

我是否也应该将它们分割成单独的域，GetUsersWithAParticularPreference在models/users中，GetPreferencesForParticularUser在models/users/preferences中，而不管它们访问哪个数据库/表？

如果我在理解DDD方面也出了问题，请指导我。

编辑：

我知道我上面发的那些案子可能有点太基础了。然而，我正在努力使我的基础正确，并设置一些指导方针，以建立一个基础。

Answer 1

我想你可能从DDD开始就错了。对于使用这种方法来说，掌握“域”是什么是非常重要的。你在这里给出的例子主要是技术性的。这里最接近域的是用户，但这是一个相当摇摇晃晃的起点。为了学习这一点，您应该真正专注于一个真正的业务领域。

所以，首先，忘掉你在这里的一切。暂时搁置编写代码。您首先需要确定您的系统要完成什么任务。听起来你可能什么都没想到，所以选点什么吧。有一些众所周知的标准实践用例:宠物商店，音乐盘存系统等.

Answer 2

DDD有不同的方面。战略和战术。战略设计是将您的业务划分到不同的有限上下文中，以便更好地为您的业务服务。当分割上下文时，其中一个应该对另一个上下文的依赖性最小。

因此，将解决方案分解为不同的上下文需要使用业务知识。

DDD是解决复杂的业务问题。您要解决的问题不是一个复杂的业务问题，DDD将是一个过头的问题。