面向服务的体系结构和域驱动设计

我一直以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是什么？

来源

2010-03-18 null_pointer

有关领域驱动设计中最重要的事情是大局观念：

通用语言，
的战略决策，你是通过在核心领域工作增加值（和将自己与其他讨厌的系统隔离开来），以及通过将基础结构与业务逻辑分离来制作可测试的灵活设计的方法。

这些是广泛适用的，是最有价值的作品。

关于工厂，服务，存储库，聚集等有很多设计模式的东西，我把这个建议从一个有经验的开发人员转移到另一个，而不是福音，因为它的大部分可以根据您正在使用的语言和框架。因为像我们这样的程序员是面向细节的，我们对这种东西很着迷，所以他们往往被过分强调。那里也有宝贵的东西，但它需要保持透视。因此，其中一些可能与你无关，或者随着你的使用而增加。

所以我想说这不像是你可以通过确保你使用所有模式的清单，这是一个牢记大局的问题，并且看到如何改变你开发软件的方法。如果你从模式中选择一些好的提示，那也很棒。

特别是关于SOA的事情，我开发的应用程序将所有状态都推迟到已使用持久性无关域对象的数据库。编写测试服务必须嘲笑daos并回馈东西是苦差事，我可以把更多的逻辑放在域对象中，我不得不在服务中嘲笑嘲笑，所以我倾向于更好地使用这种方法。

来源

2010-04-16 19:03:10

我认为一个常见的误解是，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”这需要一个订单实体，并试图在新的会话来更新这个服务？

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

每个命令都可以作为一个操作公开，也可以有一个服务操作接收命令组，然后将这些命令委托给命令处理程序。

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

来源

2010-05-06 08:45:14

我觉得这绝对是美丽的。 – 2010-08-12 00:43:32

我终于提出了一些关于此的帖子：服务+命令模式+ DDD http://rogeralsing.com/2013/12/02/using-command-pattern-to-capture-language-and-intent-for-服务/ – 2013-12-03 10:27:37

有些信息为什么旧的DTO方法不好http：// rogeralsing。com/2013/12/01/why-mapping-dtos-to-entities-using-automapper-and-entityframework-is-horrible/ – 2013-12-03 10:28:04

DDD中引入了一些概念，在构建SOA时实际上可能会让您感到困惑。

我不得不完全同意another answer，SOA服务公开了充当原子命令的操作。我相信一个非常干净的SOA使用消息而不是实体。然后服务实现将利用域模型来实际执行操作。

但是DDD中有一个叫做“域服务”的概念。这与应用程序服务稍有不同。通常，“域服务”的设计与域模型的其他部分使用相同的无处不在的语言，并且表示业务逻辑不适合实体或价值。

域服务不应与应用程序服务混淆。实际上，应用程序服务可能很好地实现，使其使用域服务。毕竟，应用程序服务可以完全封装SOA中的域模型。

来源

2010-08-12 00:50:05

面向服务的体系结构和域驱动设计

回答

相关问题