随着面向服务及面向构件思想的深入，开发人员在开发新的应用系统时往往也会把这些思想引入其中。现在对于那些较大规模的应用系统，开发人员通常期望根据该应用系统所涉及的问题域将应用系统划分为多个服务（构件），这些基础服务提供针对相关问题域的服务，并通过一个更高层次的服务（构件）来将这些基础服务根据特定的业务流程组成针对特定业务应用的系统。而这些影响所带来的设计选择在实际设计过程中必须慎重的思考和权衡，本文比较了在面向服务的构件化设计思路下两种域模型的处理方式

　　图表 1 面向服务的构件化应用系统架构

　　这种结构同样需要与我们的经典的应用软件分层结构相结合，首先我们先回顾一下经典的多层结构，经典的多层系统通常划分为以下几层：表现层，业务逻辑层及域模型层

 
　　图表 2 经典的三层架构

　　将这两种模型结合，在经典的横向划分的情况下根据上文中面向服务的构件化参考架构，进行一些纵向的划分，根据问题域所涉及的方面将系统划分为多个构件，位于基础服务层的构件通常会涉及一些域模型及问题域的逻辑。

　　在这种情况下通常会见到两种域模型的处理方法

　　将域模型分割放入各个服务构件，为了实现服务更好的可复用性通常还要对一些域模型进行进一步的泛化（然而这种泛化通常对于整合应用系统所提供的业务逻辑来说是不必要的）

　　各个服务构件共享域模型，不对域模型进行分割，当然各构件通常只会使用到相关的一些域模型。

　　这两种选择，会严重影响系统的特性（重用性，可维护性，可扩展性等）及构件的可重用性。对于方法1，由于将域模型进行了分割，所以高层的服务构件通常会定义与应用业务更为关系密切的域模型，这些域模型将建立多个下层服务构件中不同域模型间的关系。

 
　　图表 3 划分构件

　　下面以一个简单的网上售书系统为例，经过对主域对象的分析，可以发现可以将主域对象分为三个大的问题域：库存管理，订单管理，客户管理。按照这个划分我们可以划分出三个基础服务构件，对于构件相关的域模型的处理如果按照上面提及的方法一，我同样可以划分为三个部分；其中我们对订单管理部分进行了一定的泛化，可以发现这样可以让订单模块更加便于在别的系统中复用。

 
　　图表 4 售书系统域模型

　　图表 5 按方法一进行划分

　　在这种方式下更高层的服务构件，通过这些基础服务构件来完成应用所有实现的业务，那些在分割中所遗失的域对象的关联关系，将在这些高层的构件中进行补充，因此高层的构件实际上会维护一个自己的域对象模型，并且实现这个模型和基础服务中域模型的映射。

　　这种方案在一定程度上会提供基础构件的可复用性，但是它会大大降低程序的运行效率和增加程序的复杂性。

　　相反如果选择方案二，则可以获得更好的效率，但是构件的复用性会受到一定程度的影响。

　　综述

　　在使用上文提到的方法一来构建应用时一定要注意它所带来的负面影响，对于一些涉及到已有系统整合来实现的新的应用，方案一是最佳选择，这时主域对象的映射和转化在所难免。在产品线设计时，通常要求构件在不同的产品中尽量复用，即便是这时方法一同样要慎用，考虑是否对产品系列进行整体建模或是采用共享内核形式（Domain Driven-Design architecture [Evans DDD]）。

　　原文出处：http://gocom.primeton.com/blog9688_3229.htm