域驱动设计可以用例驱动吗？

Posted 2021-05-03

也许这个问题是矛盾的，但DDD从用例开始开发是否正确，然后你开发了支持这些服务的领域模型？

如果设计是由域驱动的（如DDD所说），则假设您首先开发域模型（通过了解问题域并使用泛在语言），然后开发将使用的应用层（用例）使用域名。

但是，似乎在DDD中，您首先从用例（或用户故事）开始，然后开发域模型。

答案

如果设计是由域驱动的（如DDD所说），则假设您首先开发域模型（通过了解问题域并使用泛在语言），然后开发将使用的应用层（用例）使用域名。

但是，似乎在DDD中，您首先从用例（或用户故事）开始，然后开发域模型。

这些陈述都不准确。 DDD的驱动部分并不意味着系统实现中的特定顺序。它只是说整个设计和编码工作应该主要围绕域及其语言。

您可以先选择首先将应用层实现为域层。无论如何，在开始实施之前，域的逻辑模型都需要存在。用例与域模型使用相同的语言 - 开发应用程序层没有任何意义，至少没有明确定义的无处不在的语言和草图模型。

另一答案

正如域名驱动设计所暗示的那样，域名是中心。所以你先建模域名。

因此，您需要与领域专家交谈，并且您需要为interdisciplinary team中的每个人建立对该域的良好理解。其中一部分是找到/创建无处不在的语言，确保每个人用相同的词语表示相同的事物，因此您的目标是消除基于不明确的术语的冗余和误解。

我写了一篇关于DDD and co.的博客文章系列，你可能会感兴趣。此外，我在Auth0博客上撰写了this blog post，其中描述了如何使用DDD，事件源和CQRS以及wolkenkit从头开始建模和构建软件，given(new User("an id", "[e-mail]")) .when(new ActivateUserEmailCommand(input)) .then(new EmailUserWasActivated()) 是javascript和Node.js的开源CQRS和事件源代码框架。 。

拥有域模型和无处不在的语言后，您就可以开始定义用户故事了。实际上，一旦您对域进行建模，这是一项非常简单的任务。

另一答案

根据我的经验，我建议从用例（应用程序层）开始实现。这里有一些原因：

• 用户故事以用例的形式出现：“注册用户”，“下订单”等等。所以对我来说从那里开始编码更自然。
• 由于用例的输出是通过从域返回/发布一些事件的状态转换，我使用它们首先创建测试，如下所示：

.

qazxswpoi

• 一旦我为每个不同的场景实现了测试，我的用例可以通过我甚至可以将测试类传递给另一个人（可能是经验较少的人）并让他实现它，因为大多数UL已经在测试本身。
• 我看到的一个好处是，您只需实现最少量的代码即可使用例工作。这样您就可以避免预先确定Aggregate Root需要哪些属性，而只关注特定用例所需的属性。
• 通过仅实现用例（以及测试和域），您的PR将更容易被审查，因为审阅者只看到使用的内容，并且他们不应该找到尚未使用的属性/参数，因为它将会他们更难理解添加它们的原因是什么。

另一答案

DDD并不意味着实施中的任何“订单”。 但是，它在理解域方面付出了很多努力，并尽可能地使其最明确。 根据项目的不同，可能需要数月才能充分了解域名，我认为软件应该随着域名的团队知识而发展。

所以，我认为你应该从用例，编写测试，实现/演化域，完成用例，使测试通过，确保一切正常，并与下一个用例一起开始（以非常敏捷的心情）。

因此，您的应用程序中的域层将不断发展，并且随着您获得更多有关它的知识，将通过新概念和对您的域的理解进行改进。

UPDATE 这种方法的难点在于保持用例的快速开发，因此可以轻松地重构模型。要做到这一点，所有干净的代码，设计模式以及发现做“好”代码的所有技巧都会有所帮助。 可能很难重构的可能是持久化数据。拥有持久化数据的数据结构重构可能非常痛苦，因此事件采购技术与DDD有很多关联。 （以简单的方式）它以存储不可变数据结构为中心，您的“域模型”只是这些数据的内存投影，因此您可以重构模型而无需重构持久数据。