在介绍了领域驱动设计之后，我意识到 DDD 专注于业务模型，而不是任何特定的框架/语言/或技术。作为一个数据驱动的心态持有者(x)，我正在努力确定在我们的实际项目中实施 DDD 的步骤。我想知道现实世界中 DDD 实施的实际步骤是什么。例如：
还是别的什么？
【问题讨论】：
标签： domain-driven-design use-case
我通常在开始时做的是识别域中的所有实体。
例如，让我们采用典型的博客方法。
我们可以拥有这些实体、用户、帖子和管理员。
有时不可能一开始就识别出所有这些，所以我没有得到分析paralisys，而是先处理代码。
所以对我来说下一个自然步骤是确定这些实体如何在它们之间进行协作。是写帖子的用户吗？那么我们在代码中展示一下吧：
$user->create(new Post($title, $body));
那么也许管理员需要审核帖子以接受它并将其显示在页面中：
$admin->reviewPostFrom($user);
如您所见，我们试图使代码尽可能自然，这就是我们的想法，以便能够向领域专家解释代码。
接下来是通过定义用例，我们可以创建应用程序需要的操作。
我们可以使用命令的方式，例如：
class CreateNewPost
{
protected $userId;
protected $postTitle;
protected $postBody;
public function __construct(UserId $idUser, PostTitle $postTitle, PostBody $postBody)
{
// Here we can make some kind of validation of the data
}
}
接下来我们将命令发送到我们的命令总线，后者将负责处理该命令。它在所有用例发生的命令处理程序中：
class CreateNewPostHandler
{
// here we inject all dependencies we need to accomplish our use case
public function __construct(UserRepositoryInterface $userRepo, etc..)
{
$this->userRepository = $userRepo;
etc...
}
public function handle(CreateNewPost $command)
{
$user = $userRepo->getById($command->userId);
$user->create(new Post($command->getTitle(), $command->getBody()));
// Maybe we can launch an event here that launches a notification to admin, etc.
$this->eventDispatcher(new PostCreatedEvent($user));
}
}
如您所见，我们在编写代码时并没有考虑很多我们意识到需要的事情。我希望它对你感兴趣！！
【讨论】：
领域驱动设计鼓励增量开发，而不是瀑布式开发。 DDD 是关于对复杂领域的理解，它根本无法一口气完全发现。我建议经常重复您给出的步骤。
另一件事是用例和业务需求与领域模型高度耦合。单独创建它们真的很难。
【讨论】：