領域驱动设计和开发实战.docVIP

领域驱动设计和开发实战 背景 领域驱动设计（DDD）的中心内容是如何将业务领域概念映射到软件工件中。大部分关于此主题的著作和文章都以Eric Evans的书《领域驱动设计》为基础，主要从概念和设计的角度探讨领域建模和设计情况。这些著作讨论实体、值对象、服务等DDD的主要内容，或者谈论通用语言、界定的上下文（Bounded Context）和防护层（Anti-Corruption Layer）这些的概念。 本文旨在从实践的角度探讨领域建模和设计，涉及如何着手处理领域模型并实际地实现它。我们将着眼于技术主管和架构师在实现过程中能用到的指导方针、最佳实践、框架及工具。领域驱动设计和开发也受一些架构、设计、实现方面的影响，比如： 业务规则 持久化 缓存 事务管理 安全 代码生成 测试驱动开发 重构 本文讨论这些不同的因素在项目实施的整个生命周期中怎样对其产生影响，还有架构师在实现成功的DDD中应该去寻求什么。我会先列出领域模型应该具备的典型特征，以及何时在企业中使用领域模型（相对于根本不使用领域模型，或使用贫血的领域模型来说）。 文章包括一个贷款处理示例应用，来演示如何将设计立场、以及这里讨论的开发最佳实践，应用在真实的领域驱动开发项目之中。示例应用用了一些框架去实 现贷款 处理领域模型，比如Spring、Dozer、Spring Security、JAXB、Arid POJOs和Spring Dynamic Modules。示例代码用Java编写，但对大多数开发人员来说，不论语言背景如何，代码都是很容易理解的。 引言 领域模型带来了一些好处，其中有： 有助于团队创建一个业务部门与IT部门都能理解的通用模型，并用该模型来沟通业务需求、数据实体、过程模型。 模型是模块化、可扩展、易于维护的，同时设计还反映了业务模型。 提高了业务领域对象的可重用性和可测性。 反过来，如果IT团队在开发大中型企业软件应用时不遵循领域模型方法，我们看看会发生些什么。 不投放资源去建立和开发领域模型，会导致应用架构出现“肥服务层”和“贫血的领域模型”，在这样的架构中，外观类（通常是无状态会话Bean）开始 积聚越 来越多的业务逻辑，而领域对象则成为只有getter和setter方法的数据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的外观类中（有些 情况下还会出现重复的逻辑）。 在大多数情况下，贫血的领域模型没有成本效益；它们不会给公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需求变更，开发并部署到生产环境中去要花费太长的时间。 在考虑DDD实现的项目中各种架构和设计因素之前，让我们先看看富领域模型的特性： 领域模型应该侧重于具体的业务操作领域。它应该结合业务模型、策略和业务流程。 它应该与业务中的其它领域，还有应用架构中的其它层隔离开来。 它应该可重用，以避免相同的核心业务领域元素有任何重复的模型和实现。 模型应该设计得与应用中的其它层松耦合，这意味着领域层与上下两层（即数据库和外观类）都没有依赖关系。 它应当是一个抽象的、清晰划分的层次，以使维护、测试、版本处理更容易。可在容器外（从IDE中）对领域类进行单元测试。 它应该用POJO编程模型来设计，没有任何技术或框架依赖性（我总是告诉公司里我工作的项目团队，我们软件开发用的技术是Java）。 领域模型应该独立于持久化实现的细节（尽管技术确实会对模型有一些限制）。 它应该最小程度地依赖于任何基础设施框架，因为它将比这些框架更经久，我们也不希望与任何外部框架紧耦合。 为了实现软件开发中更高的投资回报率（ROI），业务单位和IT的高级管理人员必须在业务领域建模及其实现的投资上（时间、金钱和资源）全力以赴。让我们来看看实现领域模型需要的其它因素。 团队应该经常接近业务领域主题专家。 IT团队（建模者、架构师和开发人员）应具备良好的建模、设计技能。 分析师应该具有良好的业务流程建模技能。 架构师和开发人员应该有丰富的面向对象设计（OOD）和编程（OOP）经验。 领域驱动设计在企业架构中的作用 领域建模和DDD在企业架构（EA）中发挥着重要的作用。因为EA的目标之一就是结合IT和业务部门，业务实体的代表——领域模型就是EA的核心部分。这就是为什么大多数EA组件（业务或基础设施）应该围绕领域模型设计和实现的原因。 领域驱动设计和SOA 面向服务的体系架构（SOA）最近帮助团队构建基于业务流程的软件构件和服务、加速新产品上市时间的势头越来越强劲。领域驱动设计是SOA的一个关键因素，因为它有助于封装领域对象中的业务逻辑和规则。领域模型也提供了定义服务契约使用的语言和上下文。 如果还没有领域模型，SOA的实行就应该包括领域模型的设计和实现。如果我们太过强调SOA服务、忽略了领域模型的重要性，那我们在应用架构