领域驱动设计和开发实战

1、领域驱动设计和开发实战背景领域驱动设计（DDD）的中心内容是如何将业务领域概念映射到软件工件中。大部分关于此主题的著作和文章都以Eric Evans的书领域驱动设计为基础，主要从概念和设计的角度探讨领域建模和设计情况。这些著作讨论实体、值对象、服务等DDD的主要内容，或者谈论通用语言、界定的上下文（Bounded Context）和防护层（Anti-Corruption Layer）这些的概念。本文旨在从实践的角度探讨领域建模和设计，涉及如何着手处理领域模型并实际地实现它。我们将着眼于技术主管和架构师在实现过程中能用到的指导方针、最佳实践、框架及工具。领域驱动设计和开发也受一些架构、设计、实现方面的影响，比如： 业务规则 持久化 缓存 事务管理 安全 代码生成 测试驱动开发 重构本文讨论这些不同的因素在项目实施的整个生命周期中怎样对其产生影响，还有架构师在实现成功的DDD中应该去寻求什么。我会先列出领域模型应该具备的典型特征，以及何时在企业中使用领域模型（相对于根本不使用领域模型，或使用贫血的领域模型来说）。文章包括一个贷款处理示例应用，来演示如何将设计立场、以及这里讨论的开发最佳实践

2、，应用在真实的领域驱动开发项目之中。示例应用用了一些框架去实 现贷款 处理领域模型，比如Spring、Dozer、Spring Security、JAXB、Arid POJOs和Spring Dynamic Modules。示例代码用Java编写，但对大多数开发人员来说，不论语言背景如何，代码都是很容易理解的。引言领域模型带来了一些好处，其中有： 有助于团队创建一个业务部门与IT部门都能理解的通用模型，并用该模型来沟通业务需求、数据实体、过程模型。 模型是模块化、可扩展、易于维护的，同时设计还反映了业务模型。 提高了业务领域对象的可重用性和可测性。反过来，如果IT团队在开发大中型企业软件应用时不遵循领域模型方法，我们看看会发生些什么。不投放资源去建立和开发领域模型，会导致应用架构出现“肥服务层”和“贫血的领域模型”，在这样的架构中，外观类（通常是无状态会话Bean）开始 积聚越 来越多的业务逻辑，而领域对象则成为只有getter和setter方法的数据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的外观类中（有些 情况下还会出现重复的逻辑）。在大多数情况下，贫血的领域模型没有成

3、本效益；它们不会给公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需求变更，开发并部署到生产环境中去要花费太长的时间。在考虑DDD实现的项目中各种架构和设计因素之前，让我们先看看富领域模型的特性： 领域模型应该侧重于具体的业务操作领域。它应该结合业务模型、策略和业务流程。 它应该与业务中的其它领域，还有应用架构中的其它层隔离开来。 它应该可重用，以避免相同的核心业务领域元素有任何重复的模型和实现。 模型应该设计得与应用中的其它层松耦合，这意味着领域层与上下两层（即数据库和外观类）都没有依赖关系。 它应当是一个抽象的、清晰划分的层次，以使维护、测试、版本处理更容易。可在容器外（从IDE中）对领域类进行单元测试。 它应该用POJO编程模型来设计，没有任何技术或框架依赖性（我总是告诉公司里我工作的项目团队，我们软件开发用的技术是Java）。 领域模型应该独立于持久化实现的细节（尽管技术确实会对模型有一些限制）。 它应该最小程度地依赖于任何基础设施框架，因为它将比这些框架更经久，我们也不希望与任何外部框架紧耦合。为了实现软件开发中更高的投资回报率（ROI），业务单位和IT的高级管理人

4、员必须在业务领域建模及其实现的投资上（时间、金钱和资源）全力以赴。让我们来看看实现领域模型需要的其它因素。 团队应该经常接近业务领域主题专家。 IT团队（建模者、架构师和开发人员）应具备良好的建模、设计技能。 分析师应该具有良好的业务流程建模技能。 架构师和开发人员应该有丰富的面向对象设计（OOD）和编程（OOP）经验。领域驱动设计在企业架构中的作用领域建模和DDD在企业架构（EA）中发挥着重要的作用。因为EA的目标之一就是结合IT和业务部门，业务实体的代表领域模型就是EA的核心部分。这就是为什么大多数EA组件（业务或基础设施）应该围绕领域模型设计和实现的原因。领域驱动设计和SOA面向服务的体系架构（SOA）最近帮助团队构建基于业务流程的软件构件和服务、加速新产品上市时间的势头越来越强劲。领域驱动设计是SOA的一个关键因素，因为它有助于封装领域对象中的业务逻辑和规则。领域模型也提供了定义服务契约使用的语言和上下文。如果还没有领域模型，SOA的实行就应该包括领域模型的设计和实现。如果我们太过强调SOA服务、忽略了领域模型的重要性，那我们在应用架构中最终得到的就是一个贫血的领域模型和臃肿的

5、服务。理想的情况是，在开发应用层和SOA组件的同时，迭代地实现DDD，因为应用层和SOA组件都是领域模型要素的直接消费者。使用丰富的领域实现，通 过给领 域对象提供一个壳（代理），SOA设计将变得相对简单。但如果我们太过于关注SOA层，在后端却没有一个像样的领域模型，业务服务就会调用不完整的领域模 型，这可能会导致出现一个脆弱的SOA架构。项目管理领域建模项目通常包括以下步骤： 首先为业务流程建模并文档化。 选择一个候选的业务流程，与业务领域专家一起使用通用语言来文档化业务流程。 识别候选业务流程需要的所有服务。这些服务本质上可以是原子的（单步的）或组合好的（多步的，有无工作流皆可）。它们也可以是业务（比如承保或资金）或基础设施（比如电子邮件或工作调度）。 对上一步识别的服务所使用的对象，确定并文档化其状态和行为。一开始关注业务领域核心元素的时候，就将模型保持在高水平是非常重要的。从项目管理的观点来看，真实的DDD实现项目和其它软件开发项目所包含的阶段是一样的。这些阶段包括： 对领域进行建模 设计 开发 单元测试和集成测试 基于设计和开发来完善、重构领域模型（模型概念的持续集成（CI）

6、。 使用更新的领域模型重复上述步骤（领域实现的CI）。非常适合在这里使用敏捷软件开发方法学，因为敏捷方法注重于交付商业价值，恰好DDD侧重于结合软件系统和业务模型。此外，就DDD迭代的特性来 说，SCRUM或DSDM这样的敏捷方法对项目管理来说也是更好的框架。结合使用SCRUM（适用于项目管理）和XP（适用于软件开发目标）方法对处理 DDD实现项目来说非常好。DDD迭代周期的项目管理模型如图1所示。图1. DDD迭代周期图（点击查看大图）领域建模结束时可以开始领域驱动设计。关于如何开始实现领域对象模型，Ramnivas Laddad推荐如下的步骤。他强调要更侧重于领域模型中的领域对象，而不是服务。 从领域实体和领域逻辑开始。 不要一开始就从服务层开始，只添加那些逻辑不属于任何领域实体或值对象的服务。 利用通用语言、契约式设计（DbC）、自动化测试、CI和重构，使实现尽可能地与领域模型紧密结合。从设计和实现的角度来看，典型的DDD框架应该支持以下特征。 应该是一个以POJO（如果你的公司以.Net为主营，就是POCO）为基础的架构。 应该支持使用DDD概念的业务领域模型的设计和实现。 应

7、该支持像依赖注入（DI）和面向方向编程（AOP）这些概念的开箱即用。（注：稍后将在文章中详细解释这些概念）。 与单元测试框架整合，比如JUnit、TestNG、Unitils等。 与其它Java/Java EE框架进行良好的集成，比如JPA、Hibernate、TopLink等。示例应用本文中使用的示例应用是一个住房贷款处理系统，业务用例是批准住房贷款（抵押）的资金申请。将贷款申请提交给抵押放贷公司的 时候，首先要通过承保过程，承保人在这一过程中根据客户的收入详情、信用历史记录和其它因素来决定批准还是拒绝贷款请求。如果贷款申请获得承保组的批准， 就进入贷款审批程序的结清和融资步骤。贷款处理系统中的融资模块自动给贷款人支付资金。通常，融资过程从抵押放贷公司（通常是银行）将贷款包递交给产权公司开始。接着产权公司评估贷款包，并与房产买卖双方一起确定结清贷款的时间。贷款人和卖方与结算中介在产权公司会面、签署书面协议，来转移房产产权。架构典型的企业应用架构由下面四个概念上的层组成： 用户界面（表现层）：负责给用户展示信息，并解释用户命令。 应用层：该层协调应用程序的活动。不包括任何业务逻辑，不保

8、存业务对象的状态，但能保存应用程序任务过程的状态。 领域层：这一层包括业务领域的信息。业务对象的状态在这里保存。业务对象的持久化和它们的状态可能会委托给基础设施层。 基础设施层：对其它层来说，这一层是一个支持性的库。它提供层之间的信息传递，实现业务对象的持久化，包含对用户界面层的支持性库等。让我们更详细地看一下应用层和领域层。应用层： 负责应用中UI屏幕之间的导航，以及与其它系统应用层之间的交互。 还能对用户输入的数据进行基本（非业务相关）的验证，然后再把数据传到应用的其它层（更底层）。 不包含任何业务、领域相关的逻辑、或数据访问逻辑。 没有任何反映商业用例的状态，但却能处理用户会话或任务进展的状态。领域层： 负责业务领域的概念，业务用例和业务规则的相关信息。领域对象封装了业务实体的状态和行为。贷款处理应用中的业务实体例子有抵押（Mortgage）、房产（Property）和贷款人（Borrower）。 如果用例跨越多个用户请求（比如贷款登记过程包含多个步骤：用户输入贷款详细信息，系统基于贷款特性返回产品和利率，用户选择特定的产品/利率组合，最后系统会用这个利率锁定贷款），还可以管理业

9、务用例的状态（会话）。 包含服务对象，这些服务对象只包含一个定义好的、不属于任何领域对象的可操作行为。服务封装了业务领域的状态，而业务领域并不适用于领域对象本身。 是商业应用的核心，应该与应用的其它层隔离开来。而且，它不应该依赖于其它层使用的应用框架（JSP/JSF、Struts、EJB、Hibernate、XMLBeans等）。下面的图2显示了应用中使用的不同架构层次，以及它们与DDD有怎样的关系。图2. 多层应用架构图（点击查看大图）下面的设计观点被认为是目前DDD实现诀窍的主要部分： 面向对象编程（OOP） 依赖注入（DI） 面向方面编程（AOP）OOP是领域实现中最重要的基本原则。应该利用像继承、封装和多态这样的OOP概念，使用Plain Java类和接口来设计领域对象。大部分领域元素是既有状态（属性）又有行为（操作状态的方法或操作）的真正对象。它们同时对应于真实世界的概念，能很合 适地适用于OOP概念。DDD中的实体和值对象都是OOP概念的典型例子，因为它们同时有状态和行为。在典型的工作单元（UOW）中，领域对象需要与其它的对象协作，无论这些对象是服务、资源库、还是工厂。领域对象还需要处理其它那些本身就横切的关 注点， 比如领域状态变化跟踪、审计、缓存、事务管理（包括事务重试）。这些都是可重用、非领域相关的关注点，通常很容易在包括领域层的整个代码中散布和重复。在 领域对象中嵌入该逻辑会导致领域层和非领域相关的代码互相纠缠、产生混乱。说到处理对象间之没有紧耦合的代码依赖关系和隔离横切关注点的时候，OOP并不能独自为领域驱动设计和开发提供极好的设计解决方案。在这是可以利用DI和AOP这样的设计概念对OOP进行补充，以尽量减少紧耦合、提高模块化、更好地处理横

《领域驱动设计和开发实战》由会员M****1分享，可在线阅读，更多相关《领域驱动设计和开发实战》请在金锄头文库上搜索。