domain-driven-design - 面向服务的架构和领域驱动设计

Question

我一直以 SOA 类型的方式开发代码。今年我一直在尝试做更多的 DDD，但我一直觉得我没有得到它。在工作中，我们的系统是负载平衡的，并且设计为没有状态。架构是:

网站

===物理层==

主要服务

==物理层==

服务器 1/服务 2/服务 3/服务 4

只有服务器 1、服务 2、服务 3 和服务 4 可以与数据库通信，主服务根据订购的产品调用正确的服务。每个物理层也是负载平衡的。

现在，当我开发一项新服务时，我尝试在该服务中考虑 DDD，即使它并不真正适合它。

我使用良好的 DDD 原则，例如实体、值类型、存储库、聚合、工厂等。

我什至尝试过使用 ORM，但它们似乎不适合无状态架构。我知道有一些方法可以解决它，例如使用 IStatelessSession 而不是 ISession 和 NHibernate。然而，ORM 只是觉得它们不适合无状态架构。

我注意到我实际上只使用了 DDD 教给我的一些概念和模式，但整体架构仍然是 SOA。

我开始认为 DDD 不适合大型系统，但我确实认为某些模式和概念确实适合大型系统。

就像我说的，也许我只是没有掌握 DDD，或者我过度分析了我的设计？也许通过使用 DDD 教给我的模式和概念，我正在使用 DDD？不确定这篇文章是否真的存在问题，但我在试图弄清楚 DDD 在整个系统中的位置以及它的真正可扩展性时产生了更多想法。事实是，我认为我什至不知道 DDD 是什么？

Answer 1

我认为一个常见的误解是 SOA 和 DDD 是两种相互冲突的风格。

IMO，它们是两个可以很好地协同工作的概念；
您创建一个封装域概念的域模型，并通过服务将入口点公开到该模型中。

我也看不出 ORM 和服务有什么问题，您可以轻松地在每个服务调用中使用 session /uow。
只需将您的服务操作建模为原子域命令。

一个天真的例子:

[WebMethod]
void RenameCustomer(int customerId,string newName)
{
    using(var uow = UoW.Begin())
    {
        var customerRepo = new CustomerRepo(uow);
        var customer = customerRepo.FindById(customerId);
        customer.Rename(newName);
        uow.Commit();
    }
}

也许您面临的问题是您创建了像“UpdateOrder”这样的服务，它接受一个订单实体并尝试在新 session 中更新它？

我尽量避免使用这种服务，而是将它们分解为更小的原子命令。

每个命令都可以作为一个操作公开，或者您可以有一个单独的服务操作来接收命令组，然后将这些命令委托(delegate)给命令处理程序。

IMO，这样你可以更好地暴露你的意图。