ESB zone

领域驱动设计在SOA架构中的实践

本着实践–阅读–思考–再实践的原则，总结一下领域驱动设计在SOA架构中的实践，关于领域模型设计自身，我建议大家阅读《领域驱动设计》一书，关于领域驱动实践的入门教程，我强烈建议阅读《领域驱动设计和开发实战》；关于领域驱动实践的再一个实践入门，我建议阅读《Domain-Driven Design in an Evolving Architecture》。2篇文章中，作者还提供了架构图，它们已经能够满足大部分应用的架构需求。

1.为什么要在SOA架构中使用领域驱动设计？之所以采用SOA，不是因为好玩，而是业务复杂性导致的，迫不得已而为之呀（可参考《SOA、服务化》栏目内的一些文章）。使用了SOA架构，不代表业务复杂性自动消失，还是从业务入手分析之，从目前广泛流行的方法学中，领域驱动设计完全符合符合这个需求，它就是为解决业务复杂性而生的。

2.职责分离。有时候，由于资源的情况，会让一个人同时承担技术架构和业务系统分析的角色，这种情况下，往往会搞的这个领域驱动设计乖乖的，简单玩玩也是无所谓了，对于较大的互联网公司，就是比较头疼的事情了，应用系统的开发者不同，这架构风格绝对会千奇百怪。因而还是要把这职责分清楚，搞一个技术架构师，再搞一个业务系统分析师。

• 技术架构师：关注与领域驱动设计在SOA架构中的技术部分，重点在“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。这些东西确定下来之后，技术架构风格就完全定型，下面的工作就是把架构风格“固化”，此时有2中策略，固化为框架、固化为产品，建议在头2个项目迭代中，以框架形式提供，之后就可以考虑以产品方式提供（可参考通用技术系列文章）。有了“领域驱动”在SOA架构中的支撑框架（产品），将大大的简化业务系统分析师的工作，但距离成功还有70%的距离（只有业务成功了，才是成功），可这30%将占据80%的质量属性，严重影响全局SOA架构体系的成功。
• 业务系统分析师：关于业务，关注领域驱动设计，请千万忘记技术，相信我们的战友会解决这些问题的。

3. 领域驱动设计概念架构风格图A，该风格比较保守一下，在具体cache的使用上，有2中选择，或者领域中使用，或者仓储中使用，具体那种方式适合，要看领域模型和缓存需求，不是啥都适合通过仓储缓存。

4. 领域驱动设计概念架构风格图B，该模型的变化之处在增加了一个事件层。好处：领域模型与仓储模型、cache模型等隔离，同时提供了扩展机制；缺点：不如风格图A那么直接，容易理解，且事件层放在这儿有点不伦不类。在使用中注意几点：事件对象可以业务域统一一个，或者技术框架层统一一个；建立事件标识契约，例如领域对象的类型；保证事务，避免跨线程。

5.注意以下几点：

• 领域切分不要太小，切不可变成简单的分布式方法的调用。
• SOA重用的是服务，不是功能。
• 服务应该与需求用例对应；服务提供的方法与设计用例对应（设计用例是对需求用例的实现）。
• 领域内部的复杂度与业务能力体系相关，领域不是平面的、是树状的、是有层次的，可以用层模式来切分领域对象。
• 领域内部既有用户看见的东西，也有用户看不见的业务内能力，对外暴露的值对象信息，往往来自最上层的领域对象。
• 即使一人身兼2职，也要把自己切分开，搞技术架构时，忘记具体业务，把架构风格固化下来，请开发程序员按照这个编程模型来开发；搞领域驱动设计时，完全忘掉技术。
• 如果作为公司的架构师角色进入项目团队，那么请：走入程序员中间，走入项目中间，但不要走入业务编码中间；到这儿是获取需求，验证框架（验证架构风格），发现问题的；目标是整个SOA架构的成功，不仅仅是项目的成功。
• 服务对象层，请参考《SOA实践之：Java服务接口设计的一些实践准则》，务必形成严格的编程规范，强制遵守。