随着 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）定义的是一组基础对象，它们用于语义数据模型、构建服务、以及在它们之间传递信息。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论