领域驱动设计：工作流程逻辑在哪里？
在我的项目中，我有一个在多个实体上运行以完成业务交易的工作流程。表示工作流逻辑的最佳位置是什么？目前我只是创建一个“XXXManager”，它负责与实体对象协作以完成业务交易。还有其他选择吗？
In my project,i have workflow which operates on multiple entities to accomplish a business transaction. What is the best place to represent the workflow logic? currently i just create a "XXXManager" which is responsible for collaborating with entity objects to conclude a business transaction. Are there other options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我想说，与多个实体合作来完成某件事，你正在做正确的事情。重要的是，每个实体（实际上是每个服务）都应该有一个单一职责。
您所讨论的总体工作流程可以视为应用程序层的一部分。
根据 Paul Gielens（转述），应用程序层的职责是消化粗粒度的请求（消息/命令）以实现某个总体目标。它通过向域服务发送消息来实现这一点。然后，它还（可选）决定向基础设施服务发送通知。
但什么是“服务”？这是一个重载的术语，但描述得很好（同样，作者：Paul Gielens）
您可能还想阅读洋葱架构了解更多想法...
I'd say you're doing the right thing having something collaborate with multiple entities to get something done. The important thing is that each entity (and indeed each service) should have a single responsibility.
The overarching workflow you're talking about is something that you can consider as a part of your Application Layer.
According to Paul Gielens (paraphrased) The Application Layer’s responsibility is to digest the course-grained requests (messages/commands) to acheive a certain overarching goal. It does this by sending a message to Domain Services for fulfillment. It then also (optionally) decides to send notifications to the Infrastructure Service.
But then what is a 'Service'?! It's an overloaded term but one that's described well (again, by Paul Gielens)
You might also want to read about Onion Architecture for more ideas...
通常有一个域对象应该实际处理被误认为“实体”的控件。
是否有一个因该工作流程而创建的实例？如果是这样，工作流逻辑可能就属于那里。考虑下面模型中的“顺序”。
替代文本 http://img685.imageshack.us/img685/4383/order.png< /a>
Oder 既是名词又是动词。 “订单”是作为“排序”结果创建的对象。像任何好的类一样，它既有数据又有行为（我不是指 getter 和 setter）。行为是与数据相伴的动态过程，即排序工作流程。 “订单”是控制器。
这就是发明 OO 的原因。
Usually there is a domain object that should actually handle the control which is mistaken for an "entity".
Is there an instance of something that gets created as a result of this workflow? If so, the workflow logic probably belongs in there. Consider "Order" in the model below.
alt text http://img685.imageshack.us/img685/4383/order.png
Oder is both a noun and a verb. The "Order" is the object that created as a result of "Ordering". Like any good class, it has both data and behavior (and I don't mean getters and setters). The behavior is the dynamic process that goes with the data, i.e., the ordering workflow. "Order" is the controller.
This is why OO was invented.
DDD 可能不完全是关于这类事情，所以我建议看一下服务层架构模式。 Martin Fowler 的书《企业架构模式》是一本解释它的好书。您也可以在 Fowler 的网站上找到该模式的描述。
DDD might not be exactly about this sort of thing, so I would suggest taking a look at the Service Layer architectural pattern. Martin Fowler's book Patterns of Enterprise Architecture is a good book that will explain it. You can find the description of the pattern on Fowler's web site as well.
创建工作流系统可能是一个令人畏惧的前景。您是否考虑过使用工作流程引擎？
如果我理解正确，您将需要创建一个管理器来跟踪工作流中与用户相关的不同事务。可能还有其他方法可以做到这一点 - 但我一直使用引擎。
Creating Workflow systems can be a daunting prospect. Have you considered using Workflow engines?
If I understand you correctly, you will need to create a manager which keeps track of the different transactions in the worklflow, related to user. There are probably other ways of doing it - but I've always used engines.
对于很好的答案，我想添加 "domain events" （链接仅指向一种可能的实现），这是埃文斯本人更加关注的事情（ “更加重视事件”）。
To the great answers, I'd like to add "domain events" (link is just to one possible implementation) which is something Evans himself has come to put more focus on ("increased emphasis on events").