问DDD和SOA应用程序

EN

根据无国籍组织的一个定义，

服务无状态原则提供了有利于通过将从服务转移到其他外部体系结构组件的状态管理开销来实现服务无状态的指导方针。

因此，状态从服务推迟到其他东西，但很明显，它并没有完全消失。

对于延迟状态的位置，所有选项都是开放的。您提到了将其存储在数据库中可能存在的性能问题，但您是否一开始就经历过这些问题？它是DDD应用程序中最常见的域状态存储形式，作为一般的良好实践，Aggregates应该是小的。

其他选项包括将状态存储在客户端、web框架提供的会话机制中、cookie中，等等。确保您了解每个状态的来龙去脉，以便做出明智的选择。

这是几乎每个服务器模型都存在的问题。您需要有一种机制来启动“会话”，并为客户端提供某种令牌(即会话句柄)，然后在随后的每个请求中使用该令牌。

在服务器实现中，您可以将会话状态保存在某个表或字典中，检索会话并根据会话的数据处理请求--尽可能长时间地保持会话活动。

如果有一段时间在会话中没有任何活动，您也可以

1. 断绝会议，或
2. 将会话状态保存在某个DB中，然后终止会话。

当用户完成时，他们就会“注销”--也会杀死会话。

因此，单个SOA请求确实是无状态的，但它们(借助会话句柄)引用有状态对象。

是否有可能以状态的方式使用SOA架构？

我想是的，就像Uebercoder说的那样。但这并不意味着你不能使用DDD。

我们都知道，这些步骤：

• 加载集料
• 更新它(内存中)
• 再坚持下去

永远不会比以下速度快：

• 只需更新数据库中的那个列

但是对于第二个选项，我们失去了DDD的一个主要好处:在代码中公开业务。如果您的所有操作只是“更新该属性并保存”，那么这个项目最终可能不会受益于DDD。

在我的经验中，在SOA架构中使用DDD在大多数情况下都是值得的。正如@guillaume31 31所说，你只需要小心你的总根的大小和边界。

只选一个你的短语：

“大型SOA应用程序”

我不太清楚这是什么意思，但请注意:在DDD中实现的单块应用程序变得非常混乱。

我认为(埃里克·埃文斯也是) DDD确实在埃里克·埃文斯也是体系结构中闪闪发光。

只是我的想法:)