面向服务的架构和域驱动设计 - 代码日志

面向服务的架构和域驱动设计

我一直以SOA类型开发代码。今年我一直在努力做更多的DDD,但是我不断得到我没有得到它的感觉。在工作中,我们的系统负载平衡,设计不具有状态。架构是:

网站

===物理层==

主要服务

==物理层==

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

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

现在,当我开发一个新的服务时,我尝试在该服务中考虑DDD,尽管它不太适合。

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

我甚至尝试使用ORM,但它们似乎并不适合无国籍的架构。我知道有办法,例如使用IStatelessSession而不是使用NHibernate的ISession。然而,ORM只是觉得他们不适合无国籍的架构。

我注意到我真的只使用DDD教授我的一些概念和模式,但整体架构仍然是SOA。

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

就像我说的,也许我只是不了解DDD,也许我正在分析我的设计?也许通过使用DDD教导我使用DDD的模式和概念?不知道这个帖子是否真的有问题,但是在尝试了解DDD在整个系统中的位置以及它的真实可扩展性时,我已经有了更多想法。事实是,我不认为我甚至不知道DDD是什么?

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

海事组织,它们是共同合作的两个概念。
您创建一个封装您的域概念的域模型,并通过服务将入口点公开到该模型中。

我也没有看到ORM和服务有什么问题,您可以轻松地使用每个服务调用的会话/ 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”,它接受订单实体,并尝试在新会话中更新此服务。

我试图避免这种服务,而是将它们分解成更小的原子命令。

每个命令可以作为一个操作公开,或者你可以有一个单一的服务操作接收命令组,然后将它们委托给命令处理程序。

IMO,这样你可以更好地揭示你的意图。

http://stackoverflow.com/questions/2467456/service-oriented-architecture-domain-driven-design

本站文章除注明转载外,均为本站原创或编译
转载请明显位置注明出处:面向服务的架构和域驱动设计