OOD vs SOA

InfoQ: OOD vs SOA Approach to SOA Domain Modeling

鉴于InfoQ中国可能对该文章翻译（需要客观观点看原文或等中文翻译），下面结合我个人DDD和SOA两方面经验，从我角度看看两者的讨论。

首先要搞清楚SOA和DDD是有区别的，SOA是以功能为划分边界，而DDD是以类为划分边界，将功能封装在类中作为方法。我个人更愿意把这两种都认为是最高意义上OO面向对象，就像现在面向函数语言Scala等也是以函数功能为划分。

初学者总是把面向函数或以功能划分和面向过程混同起来，两者本质区别就是有无边界划分。面向过程是很多功能模块混同在一起，一锅浆糊，而面向函数是以功能功能方法进行细分，松耦合解耦。

但正因为这个否定之否定，有点绕的概念，致使很多初学者使用SOA是以面向过程思维来使用，结合数据库SQL语言，我见过一个大型的SOA系统，其Web服务的定义实际就是数据表操作定义，SOA方法内部功能核心实际就是复杂一点的插入 删除 查询的SQL语句。

回头看看他们的讨论：
面向服务的建模技术(service oriented modeling )，比如具体到：面向领域的服务建模( DOSOM(Domain oriented service modeling) )是分解业务服务(SOA)的第一步，DDD是SOA的实现途径，通过基于业务功能结果基础上的领域划分，是迈向SOA的第一步。

一旦业务合约能够定义下来(由需求专家)，OOD是实现服务实现的好方式，在SOA中分析需求不同我们在Jdon提倡的用例 四色原型 然后DDD等先后方法，它是首先定义业务合同business contract，是一种合约设计(Design by Contract)，比如世界电信联盟NGOSS BOSS等都是这样SOA思路。

我曾经花不少时间研究NGOSS，实际上它和SOA一样，只不过是一个行业的SOA，同样存在SOA的缺点，只重视战略，战术指导不够，怎么实现都很含糊，结果很多电信BOSS系统都是基于关系数据库的SQL语句实现，出现我上面提到服务的方法实际就是数据库SQL语句的奇怪现象，导致系统难以维护和拓展，BUG不断，这时DDD正好可以弥补这样的缺憾。

当我们SOA中的服务是由富领域模型分解实现以后，带来的问题就是网络间传输富模型很浪费，那么大的有方法的富领域对象被序列化传输是性能杀手，现在一般使用只有setter/getter的贫血模型，实际是数据表的翻拍品，使用领域模型后，需要最小化服务之间的信息交换，可以使用一种主数据管理技术(MDM Master Data managerment)通过最小化的核心模型来实现消息。MDM我个人认为就是富领域模型的另外一种称谓。

具体谈到了Mortgage Industry Standards Maintenance Organization (MISMO)如何简化实体结构。MISMO适合作为相同行业中不同伙伴之间通讯的标准格式，对内部来说，核心领域模型使用是比较适合，因为通讯场景很少变化，也不必跨业务领域跨不同公司需要进行分享。在典型的企业内部需求中，灵活性和可维护性是必须的，而不是与其他企业通讯交换数据。

对于领域模型和SOA如何结合，我过去在Jdon帖子中也提出，SOA的服务内部委托领域模型的方法实现，SOA的服务对外是一个协定接口，打开SOA服务具体实现再看，你找不到核心功能实现代码，因为被分解到领域模型的方法中实现了，这点可以从Jivejdon的案例中可见一斑，这也是该讨论中有人分享他们的经验：Domain data is the classes that encapsulate information needed to implement services.This uses the classic object/relational mapping.
领域模型是用类来封装原本需要在服务中实现的信息数据，然后用经典的ORM映射。对于后面一句我也不敢沟通，如果说领域模型是SOA服务的分解实现，ORM则是领域模型的分解实现，有时我们不一定用ORM，用NoSQL也可以啊。这样说，会让很多初学者感觉绕了一圈还是落实到数据库，只不过中间加了多个环节，反而复杂，有脱裤子放屁嫌疑。其实虽然没多了环节，主角核心不一样了，现在主角核心是领域模型，不是数据表了。

讨论中David Tildesley 提到使用color modelling也就是jdon经常谈的四色建模，有颜色的建模技术，四色原型，结合原型领域形态(ADS)archetype domain shape 等，可以导向以组件为核心的建模方向，它认为传统的OO是以类为划分边界，有违SOA初衷。他认为每个业务组件都有其核心实体(四色原型中绿色或粉红色)，他们由黄色的角色解耦。