领域驱动建模（EvansDDD）.pptVIP

领域驱动建模(Evans DDD) 彭晨阳 欢迎联系企业培训 Evans DDD 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD 领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道 Evans DDD 领域模型重要性 没有领域模型，只是靠代码编写完成一个又一个功能，复杂的领域需求会使得他们无法交流讨论，使工作陷入泥沼。 有少许领域模型，但是没有维护好模型与代码直接的联系，两者产生差异，无法实现。 DDD优点 分析设计发展的三个阶段 第一阶段：围绕数据库的驱动设计，新项目总是从设计数据库及其字段开始。 第二层次：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，分析阶段和设计阶段是断裂的。 第三阶段：融合了分析阶段和设计阶段的领域驱动设计（Evans: DDD）。 第一阶段：传统的数据库方式 过去软件系统分析设计总是从数据库开始，这种围绕数据库分析设计的缺点非常明显： 1.分析方面：不能迅速有效全面分析需求。 2. 设计方面：导致过程化设计编程，丧失了面向对象设计的优点。 2. 运行方面：导致软件运行时负载集中在数据库端，系统性能难于扩展，闲置了中间件J2EE服务器处理性能。 对象和关系数据库存在阻抗，本身是矛盾竞争的。 第二阶段：分析和设计分裂 第二阶段比第一阶段进步很多，开始采取面向对象的方法来分析设计需求。 分析人员的职责：是负责从需求领域中收集基本概念。面向需求。 设计人员的职责：必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题 两个阶段目标不一致，导致分裂，项目失败。 新阶段：分析设计统一语言 统一领域模型，它同时满足分析原型和软件设计 ，如果一个模型实现时不实用，重新寻找新模型。 一个无处不在(ubiquitous )的语言，项目中所有人统一交流的语言。 减少沟通疑惑，减少传达走样。使得软件更加适合需求。 没有领域（边界）的模型 一个印在大纸张上的完整类图，整面墙都被它覆盖，花几个月分析开发的领域模型，模型大多数对象都与其中三四个对象有错综复杂的关系，且关系网几乎没有自然边界。分析人员是忠于领域需求本质。 问题：开发人员开始实现应用程序时，彼此纠缠的关系根本无法转换成可存储 可检索的实现。 是不是基于概念的模型类图不能成为程序设计的基础？ 领域模型在软件架构中位置 什么是领域模型 Domain Model? 某个范围内的模型。首先是边界划分，在边界中寻找代表领域本质旋律的模型。 领域模型只表达需求真实世界模型，和软件架构技术无关。 模型都是有前提和范围，或者称为有场景前提的。没有跨越范围的永恒不变的模型 。 由领域专家来定义领域模型。 名词==类名 动词==类中方法 服务或其他 机器人 机器人的领域模型 确定核心领域 大型系统中，有很多有用的组件，他们非常复杂，都是软件成功不可或缺的，这样组件实在太多，以至于领域模型的精髓部分变得不明显甚至被忽视。 不可能所有部分都进行提炼，分清轻重缓急，让领域模型真正成为资产。 核心模型必须足够灵活和充分平衡来创建应用程序功能，不要倾向于使用技术基础结构如数据库来解决问题。 无需专业业务知识容易能理解能引起程序员的兴趣，他们认为只有解决这些问题才能积累自己专业知识，同时为自己简历增光添彩，这对于公司是浪费。 不注重核心领域的案例 银团贷款系统：大多数技术天才和技术高手都对数据库映射层和消息接口津津乐道，而业务模型却交给一些刚刚涉足面向对象技术的新手们打理。 尽管为持久领域对象提供详细注解文字说明，能够反映设计思路，也设计了友好的用户界面。 这些特性都是外围，当这个软件最终交付用户使用时，差劲程序员二次开发拓展时却依然搞得一塌糊涂，整个项目差点失败。 通用子域：非核心领域 提炼核心领域，就必须剔除反面通用子域。 不同行业运输业 银行业 制造业都需要某种形式组织结构图。组织结构图就是通用子域。 许多应用跟踪应收帐款 费用分类和其他帐务信息，这些信息都可以使用通用的会计财务系统来处理。 有两个项目处理带时区功能的日期和时间组件，花费最好的程序员数周时间，虽然必须做，但不是系统核心。 考虑现有解决方案或开源公开模型来替代通用子域。 考虑外包，将通用子域外包，自己掌握核心领域。 领域中寻找核心模型 找出核心模型，提供一种方法让我们很容易地从众多支持模型中将它区分出来，将最有价值 最体现专门知识的概念凸显出来，核心变小。 让最好的程序员来处理核心模型，根据需要调整人员的配备，尽力找出核心的深