三、建立技术框架

　　这一点，是《领域驱动设计》这本书没有过多提及的内容。这个需要结合你们公司的原来技术框架用最小化改造成本最大化收益的方式来建立领域驱动的技术框架。下面是一个可以广泛使用的领域驱动的技术框架，可以在这之上增加更多的个性元素形成你公司自己的框架。

　　图3 领域驱动设计参考技术框架图

　　这个框架的各个元素基本上在 《领域驱动设计》一书中都可以找到对应的解释，但这里需要解释一下我建立这个框架的个性理解：

　　领域对外(页面、AJAX、ESB调用)只暴露领域服务，其它所有领域类都是包内自闭的，对外不可见。

　　基础仓库的引入，基础仓库是一个抽象的仓库，它封装了大量常用工具方法、业务对象生命周期维护(实体OR映射、DAO调用)、外部接口调用。可以降低业务仓库不必要的重复编码与复杂性。业务仓库是继承基础仓库的子类。

　　基础设施的引用，基础设施是用来承载引用非领域调用的桩，我们在使用领域驱动设计的时候往往是从一个旧的系统重构开始。这时我们不可能要求所有的业务子系统相互调用都通过Domain Service调用，这时我们可以通过Infrastructure优美的把调用封装在业务仓库的业务方法内。

　　四、重构受影响领域的设计与编码

　　图4 重构后的商品详情页类图

　　Spark以商品详情页这个Use Case为例展示了以领域驱动设计的重构类图：

　　增加行为表ProductExt用于存储商品的扩展信息，如预约时间段、预约医院。并为表建立一一对应的实体Entity。

　　基础仓库Repository通过Infrastructure中的DAO封装了对实体的操作，如create()、update()、delete()、findById()、findList()

　　商品业务仓库ProductRepository扩展了基础仓库，客户程序可以用productId为参数，通过ProductVo.getProduct()方法获得商品详细信息的业务实现，由于业务仓库的的公开方法对外返回的都是Value Object，因此不会直接暴露Entity类型给客户程序。

　　GetProductService服务类通过invoke()服务方法 对外(商品详情页面)提供服务，它通调用业务仓库中的业务方法，并将接口规格化。

　　在Spark的帮助下，Jack Chen成功的脱离了困境。现在他正在公司里积极推行自己的领域驱动设计框架，他们公司的网站正在以每三周一次的重构速度快速迭代演进。他象Spark一样，成为了一个领域驱动的布道者。

　　来源：InfoQ