对领域驱动设计的初步认识（四）
“一上来先识别类，然后就考虑怎么分配职责”的做法是一种本末倒置的僵化的静态建模。这种方式往往让人落入一种只注重“形”而忽略“意”（业务本来的面目）的怪圈。我认为建模分为2个阶段，第一个是“有机的业务建模”，第二个是“技术建模”。“业务建模”和“技术建模”的区别是：“业务建模”完全是业务语言，不含任何技术成分，比如“类、值对象和职责”的概念，在“技术建模”中才涉及那些概念。“业务建模”做好了，“技术建模”就成了自然而然的东西了。
“有机的业务建模”的一个非常重要的特征就是“有机”，就是强调业务模型中的每一个“业务主体”都是一个生命体。这些业务主体都有“生命特征”，在一定条件下受到外界的刺激就会发生一定的行为。这些业务主体构成了整个业务模型。当然，这些业务主体的规模和层次不同：比较大的业务主体就是“领域主体”，他有明确的领域边界；而领域主体的对外界响应其实是通过内部的“业务核心主体”的协作来完成的，有的看见的见摸得着————具有业务实体的特点，有的比较抽象————控制规则和流程，当然有的“业务核心主体”可能是个多核细胞。“有机的业务建模”有一个非常重要的工作就是“检查业务模型的生命健康状况”。需要注意的是这个业务建模可能是通过不完善的用户需求建立起来的，所以我们需要构建多种场景通过不同的刺激去看这个领域主体内部的响应中是否有“异常情况”，如果有那就要开刀了。
关于“技术建模”，我认为“对内功能和对外功能要分开”，领域对象不建议同时承担对内和对外的功能，但小项目除外。服务对外要封装和隐藏领域内部的东西，提供的是服务接口；同时服务要负责领域内部对象的行为组装。从另外一个层面看，服务是需求，领域对象模型是实现。值对象的本质就是反映业务主体的不同业务特征，可能是业务主体的临时状态（比如用户的发帖数）或者属于另一业务主体的状态值。从微观看，聚合是交互最紧密的业务对象的封装，从宏观看，聚合是一个具有明确业务边界的独立业务核心主体。所以聚合只是形式，业务模型的正确建立才是决定要素。
另外，我谈一下“面向关系设计”的意义。其实，不要一说“面向关系设计”就是错的。因为用户的角度看，业务本来就是面向关系和过程的，这非常自然；而从设计看，业务是不同主体在相互作用。这就是为什么越靠近用户的地方面向关系和过程的设计味道越浓的原因了。
[该贴被flyzb于2010-10-22 01:23修改过]