第一次听IBM的讲师（hi，Derek）讲SIMM和SOMA时，还是去年的春天，虽然他着墨不多（据说那时IBM关于SOMA之前的方法论还没有成体系，不便公开），但还是被Component Business Model吸引。我那个时候是DDD的狂热爱好者，不像现在这样对DDD做更多的思考。那个时候，只要跟DDD相关的东西，我都会考虑它跟DDD是不是有着某种神秘的扩展关系。CBM就是这样被我纳入我的关注范围的。
说实话，CBM最初能给我留下印象，主要是 它有着一个明显的责任层，在我的印象中，在large-scale Structure中使用的DDD中也有一个很明显的职责层。当然，现在仔细看上去，这两个东西并不是完成的一致的，但是确实有些隐隐绰绰的关联的影子。现在我可以负责任的说，我确实也找到了两者的联系。
因为DDD注释版出版了，我顺便去看DDD中文版的书评，DDD是一好书，直到现在很多人仍然是这么说，在对中文版的翻译提出若干的质疑后，有人写道：“喜欢前面的几章，值对象、实体、aggregate等概念第一次听说，后面的东西就显得很空洞了”（大意）。我其实对这种观点是持反对意见的，作为基础构造块，前面提到的概念确实是DDD比较能够吸引眼球的地方，但是，吸引眼球并不代表它就没有问题。具体是什么问题我先压下不表，我反对这种观点的更主要的原因是因为后几章比前几章精彩得多。
如果你有心读到《战略性设计》部分，你就会发现我前面提到的职责分层（Resposibility Layer）是很有实战意义的。很多人像读《设计模式》那样读DDD，这是错的。如果你没有把你的目光从设计转到领域上，那么你误解了Eric了。
回到Component Business Model ，我不想跟人争辩Business Model 和Domain Model是什么样的关系，是一体的还是各自独立。这没有什么意义，我们能够找到的是它能够为我们的系统做些什么，这就足够了。CBM和DDD的最密切的联系，不是在职责分层上，而是在Service上。这也是DDD为什么会列为SOMA推荐参考资料的主要原因。
今天写出来的是一个小的结论，其实，我本周（其实可以更早的追溯到我上个周去北京出差参与的那个项目期间）我就在做DDD和CBM之间的关联探究，探究的过程很有趣，我会在以后的blog中逐渐的放出我的探究过程的。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。