随着 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)定义的是一组基础对象,它们用于语义数据模型、构建服务、以及在它们之间传递信息。
评论