SOA与DDD存在共生现象吗？(转)

SOA与DDD存在共生现象吗？
作者 Boris Lublinsky译者 徐涵 发布于 2008年9月17日 下午10时2分

社区 SOA 主题 设计 标签 领域驱动设计, 领域建模, 服务设计
随着SOA渐受欢迎、在企业架构里扮演重要角色，形势愈加明显，即它得着手利用其他相关学科取得的进步。这一观点在一次关于SOA与DDD（Domain Driven Design，领域驱动的设计）关系的讨论中得到了印证。

SOA是：

一种架构风格，它提倡设计与业务齐合的企业服务，并将这些服务作为设计、构建、构思企业业务方案的核心单元
DDD是：

一种思考方式和一组优先考虑事项，它致力于加快那些涉及复杂领域的软件项目
Trond-Eirik就二者表面上的共性提出以下问题，从而引发了本次讨论：

你们认为SOA和DDD这两个概念有何异同？它们是满足彼此需求的完美搭配吗？它们是互斥概念吗？也就是说，用了DDD，就不能用SOA了？它们解决或属于问题域里的不同部分吗？还是，它们解决或属于问题域里的相同部分？
用户名为“moffdub”的网友回答说：SOA和DDD之间有着很强的互补性：

DDD是一种开发部署单元（单个应用）的方法。SOA是一种将多个部署单元粘合在一起的方法。
Ashley Fernandes提出了另一种综合两者的方式，他认为DDD是一种定义业务服务的技术：

我认为DDD里的服务层（service layer）跟UDDI里的WSDL服务非常接近。正因如此，DDD和SOA可以很好地共存。
Tomas Karlsson分享了他综合运用DDD和SOA的实际经验。他建议以纯DDD方法开始，然后创建实现了领域对象的对象（POJOs或无状态beans），并将它们暴露为服务。最终，他创建的是

一个（也可以是一组）具有明确职责的服务，即为给定对象上的增、查、改、删（CRUD）操作进行后端处理。尽早拥有这样的服务，将尽早给你的项目增加稳定性。
按照Colin Jack的说法，尽管SOA与DDD之间完全可以有共生关系，但在实现时要相当谨慎。特别地，他指出，提供实体服务（entity service）的想法会跟DDD格格不入。

我的问题是，我觉得实体服务（entity services）无法与DDD很好配合，尽管你暴露那些服务只是为了聚合，但因为你的领域设计需要改变，而且你已经丧失了“跨聚合事务”这样的基本特 性，所以你还是会遇到问题。没错，你可以在某些方面放松一些，但你要是那样做了，你还能享受SOA带来的好处吗？
Casey Charlton赞同Ashley Fernandes的观点，他认为Tomas和Colin的方法会导致大量细粒度服务的出现：

我想，你最好暴露封装了整个领域模型的大粒度服务，然后在这些服务之间进行消息传递，而不是在较低的层次上对SOA进行分解。严格照此行事才算得上是SOA。进一步细化，会违反“粗粒度服务”的原则。CRUD操作在SOA架构里肯定是无用的。
Casey Charlton的观点得到了Andreas Ohlund的支持，他引述Bill Poole的话说：“DDD是用于在粗粒度的SOA服务里构建领域逻辑的”。

没错，SOA和DDD支持同样的目标。良好设计的服务指的是那些“名字为CEO或业务总管所熟悉的、并且后者关心其具体功能的”服务。而良好设计的领域对象（well designed domain objects）定义的是一组基础对象，它们用于语义数据模型、构建服务、以及在它们之间传递信息。

查看英文原文：Is There a Symbiosis Between SOA and DDD?
Is There a Symbiosis Between SOA and DDD?