DDD和SOA应用程序

Question

我负责大型SOA应用程序。客户端是ASP.NET WebForms，业务是带有WCF的.NET。

我们的商业代码非常糟糕（BBOM），经过一些阅读后，我陷入了DDD。我真的想用DDD概念重写我们业务的某些部分。

借助SOA，我处于无国界的世界。因此，如果网页提供了用户操作订单的能力，例如添加订单明细，删除订单明细，......每个业务方法都必须重新加载数据以在应用业务规则和持续更改之前保留我的聚合。 / p>

当很少数据被篡改时，这不是问题。但是当聚合体很大并且加载数据和保湿它需要几秒钟时会发生什么呢？

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

Answer 1

这几乎是每个服务器型号的问题。你需要一个机制来开始一个会话＆＃39;并为客户端提供某种类型的令牌（即会话句柄），然后在每个后续请求中使用它们。

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

如果你的会话暂时没有活动

1. 彻底杀死会话，或
2. 将会话状态保存在某个数据库中，然后终止会话。

用户完成后，他们会退出＆＃39; - 也杀了会议。

因此，单个SOA请求确实是无状态的，但它们（通过会话句柄提示）引用有状态对象。

Answer 2

根据SOA无状态的one definition，

  

服务无国籍原则提供了有利于的指导原则   通过转移状态管理使服务成为无状态   从服务到其他一些外部架构的开销   的成分

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

所有选项均在推迟状态推迟。您提到了将其存储在数据库中的潜在性能问题，但您是否首先体验过它们？它是DDD应用程序中最常见的域状态存储形式，作为一般的良好实践，聚合应该很小。

其他选项包括在客户端中存储状态，在Web框架提供的会话机制中，在cookie中等等。确保您了解每个状态的细节以做出明智的选择。

Answer 3

  

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

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

我们都知道步骤：

• 加载聚合
• 更新它（在内存中）
• 再次坚持

永远不会快于：

• 只需更新（即）数据库中的该列

但是第二种选择我们失去了DDD的主要好处之一：在代码中公开业务。如果您的所有操作都只是更新该属性并保存＆＃34;，那么这个项目毕竟不会受益于DDD。

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

选择你的一个短语：

  

＆＃34;大型SOA应用程序＆＃34;

我不知道你对此的意思，但要注意：在DDD中实现的单片应用程序会很快变得混乱。

我认为（and Eric Evans too）DDD真的在微服务架构中闪耀。

只是我的想法：）