《领域模型驱动的开发方法.ppt》由会员分享，可在线阅读，更多相关《领域模型驱动的开发方法.ppt（54页珍藏版）》请在三一办公上搜索。
1、领域模型驱动的开发方法,1、为什么要引入领域模型,2、如何创建领域模型,3、模型驱动设计,领域模型,3,需求调研,业务流程,需求分析,概要设计,详细设计,架构设计,界面原型,编码,详细设计,J2EE WEB应用系统的目前常用的开发模式,用例,制度,表格,数据库设计,编码实现,问题？,从界面原型到表现层代码,从领域模型和架构蓝图到业务逻辑代码,C,V,M,5,需求调研,业务流程,需求分析,概要设计,详细设计,架构设计,界面原型,编码,详细设计,J2EE WEB应用系统-领域模型的引入,用例,制度,表格,数据库设计,编码实现,领域模型,从业务级需求推导出系统实现级需求,领域模型的引入,模型的3个用
2、途,模型与实现绑定没有模型的指导，复杂项目将可能陷入泥潭如果模型没有映射到设计与实现，其价值何在模型是团队成员使用的语言可以作为分析设计讨论的基础模型用来提炼与积累知识,用户的需求也许是不变的，往往变化的是我们对需求的理解,软件的核心,软件的核心为用户解决领域相关问题的能力软件系统分析人员只有学习业务领域知识，提高建模技巧，才能处理复杂问题化繁为简开发一个清晰易懂的模型来简洁的解决复杂的业务领域问题，并且模型能够明显的指导编码实现,1、为什么要引入领域模型,2、如何创建领域模型,3、模型驱动设计,领域模型,领域模型的内容,领域模型的内容1,识别实体时一个常犯的错误类还是属性？目的地Destin
3、ation是航班Flight的一个属性呢，还是一个单独的类机场Airport？,领域模型的内容,领域模型的内容2,创建领域模型,完善模型,CRC分析寻找类,名词/动词分析寻找类,根据需求（现实世界）建立词汇表，补充说明或者用例从词汇表、用例中发现名词和概念，作为业务领域的候选实体类名词暗示类或者类属性，动词暗示职责或者类的操作,类、职责、协作方第一步：使用头脑风暴法收集信息第二步：分析信息,在实体类之间添加必要的关联来明确彼此关系添加实现需求的必要属性,领域模型的开发是一个迭代的过程创建，精化1，精化2建模人员要关注编码实现过程，和编码人员紧密合作，从而改进模型,创建领域模型（例）,示例：根据
4、下面描述绘制类图,这是一个“碟片出租店”使用的程序，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租期和影片类型算出其消费金额。影片分三类：普通片、儿童片和新片。除了计算消费金额，还要为常客计算累计点数；累计点数会随着“租片种类是否为新片”而有所不同。,这是一个“碟片出租店”使用的程序，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租期和影片类型算出其消费金额。影片分三类：普通片、儿童片和新片。除了计算消费金额，还要为常客计算累计点数；累计点数会随着“租片种类是否为新片”而有所不同。,创建领
5、域模型（例）,碟片出租店程序消费金额报表操作者顾客影片租期影片类型普通片儿童片新片累积点数,这是一个“碟片出租店”使用的程序，它将用于计算每一位顾客的消费金额并打印报表。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租期和影片类型算出其消费金额。影片分三类：普通片、儿童片和新片。除了计算消费金额，还要为常客计算累计点数；累计点数会随着“租片种类是否为新片”而有所不同。,创建领域模型（例）,碟片出租店程序消费金额 报表操作者 顾客影片租期影片类型普通片儿童片新片累积点数,在系统外,系统本身,应该是每次“交易”属性,类！,在系统外,在系统外，但需记录，类！,类！,属性,影片的属性,类！,类
6、！,类！,顾客的属性,报表,顾客,影片,普通片,儿童片,交易,新片,创建领域模型（类和类之间的关系）,创建领域模型-属性、方法,实体属性的练习,词汇：Average sales volume平均销售量Product category 产品类别Sales contact 销售的联系方式Sales representative销售代表,建议,领域模型-类之间的关系,聚合关系(Aggregation)：是关联关系的一种，是强的关联关系。合成关系(Composition)：是关联关系的一种，是比聚合关系强的关系关联关系(Association)泛化关系（Generalization）：继承依赖关系（D
7、ependency）：是类与类之间的连接，依赖总是单向的,聚合,聚合强化了类间的联系给实现传递细节，意味着删除Requirement时要删除RequirementItem,关联,一对一关联：几乎总是变为组合，也可以选择使用属性或者合并2个类。多对一关联：整体的一端的多重性大于1，而部分一端的多重性是1的情况。使用聚合。一对多关联：在部分一端有一个对象集合使用内置数组使用集合类,关联类的练习,关联类是纯粹的分析制品，不能映射到OO语言，在设计模型中必须转化，可以使用聚合、组合或者依赖来捕获关联类的语义,关联类的练习,一个person可以具有多个job，每个job对应于一个company一个per
8、son在同一个company可以有多份job,意味着给定的company对象和给定的person对象之间只有一个Job对象每个Person对于给定的Company仅能具有一份Job,关联类的练习,导航,导航方向除了表示阅读关联标签的方向外，没有其他意义，通常可以忽略,服务的建模,当领域中的一个重要行为或转换操作不是实体对象本身的职责时，把操作作为一种独立的接口加入模型，并声明为服务。入库过账、入库冲红过账 出库过账、退库过账,优秀服务的三个特征：与领域概念相关的操作行为、但不是实体和值对象中固有的部分接口根据领域模型中其他元素定义操作是无状态的,模块,要符合通用原则，模块内部高内聚，模块之间低
9、耦合（关联）避免模块之间的交叉依赖依赖于同一个模块内的其他类比依赖一个外部的类要好类之间的依赖、关联、继承如何影响到模块之间的依赖,合并,分离,领域模型 RUP,RUP解释：业务建模获得领域模型，设计活动获得设计模型。设计模型的领域层的软件类是从领域模型中的名称、属性和关联中得到启发。,四种建模策略,改进,RUP割裂了领域模型和设计模型，我们应该寻找一个单独的模型来满足这两方面的要求由于公司的J2EE架构模式已经固定，我们可以进行简化，即直接使用领域模型来指导编码基于架构模式可以把领域模型转换成设计模型，转换后的设计模型是一个能够指导编码的模型,误区,一般认为领域模型是贫血模型，只有实体没有服
10、务，只有属性没有行为，这样导致转换后的设计模型中实体只有属性和默认的增删改行为，没有对外服务领域模型应该有实体和服务，类包括属性和行为。那么转换后的设计模型？,1、为什么要引入领域模型,2、如何创建领域模型,3、模型驱动设计,领域模型,Database ObjectDesign,模型驱动数据库设计,数据库对象设计采用PDM包括索引，存储过程,模型驱动,J2EE Web App.MVC Arch.Blueprint(Patterns),ArchitectureDesign,模型驱动架构设计,模型驱动,Business LogicDetail Design(AppSvc),Architecture
11、Design,模型驱动详细设计业务逻辑部分,模型驱动,Business LogicLayer Code,Presentation Layer Code,Database Object,Source Code,代码实现的组成,Business LogicDetail Design(AppSvc),Business LogicLayer Code(Delegate/Faade/AppSvc/Entity/VO/DAO)最终代码,ArchitectureDesign,模型驱动代码实现业务逻辑部分,Business LogicLayer Code Framework代码框架包括基础代码,模型驱动,Pr
12、esentation Layer Code(JSP/js/Action),PresentationDetail Design(jsp/js/action),代码实现表现层部分,表现层的详细设计可以省略,原J2EE架构模式,改进,改进前:实体的属性对应于EJB EntityBean实体默认的增删改行为对应于EJB SessionBean改进后：实体默认的增删改行为（领域模型不需要定义）对应于Application Service的行为实体的行为（领域模型定义）对应于Application Service的行为服务对应于Application Service的行为，或者作为接口被Applicati
13、on Service实现,现J2EE架构模式,领域模型中的行为业务逻辑集中在AppSvc,从模型到代码,J2EE架构模式,Action+ActionFormPurchaseForm.java,PurchaseItemForm.javaPurchaseListAction.java,PurchaseItemListAction.javaPurchaseMultiOperationAction.java,PurchaseItemMultiOperationAction.javadelegatePurchaseMan.javaSessionBean+EntityBeanPurchaseSesBean
14、.java，PurchaseItemSesBean.java，DAOPurchaseDAO.javaappservicePurchaseAppService.java,PurchaseItemAppServicemodelPurchase.java,PurchaseItem.javaexceptionPurchaseException.java,PurchaseItemException.java,从模型到详细设计,详细设计,设计思路：1、balance（RequirementItemVO itemVO）/该方法将进行平衡库存的操作If（itemVO中平衡库存数量大于零）call Invent
15、oryAppService进行调拨过账处理；/数据库状态变化将itemVO的状态置为“balanced”；,附录,设计原则,Design Principles,开闭原则（Open Closed Principle）对扩展开放而对变更封闭open for extension but closed for modification,Design Principles,依赖倒置原则（Dependency Inversion Principle）依赖于抽象类而非具体类depend upon abstractions but concretions,Design Principles,Liskov 替换
16、原则（Liskov Substitution Principle）子类应当能完全替代其基类的行为subclasses should be substitutable for their base classes,Design Principles,单一职责原则（Single Responsibility Principle）一个类只应当承担单一和集中的职责，这样引发类进行变更的原因只有一个A class should have one,and only one,reason to change,Design Principles,接口分离原则（Interface Segregation Pri
17、nciple）为客户提供多个特定的接口好过一个多种用途集于一身的接口，即客户不被强制依赖于其不需要（不使用）的操作many client specific interfaces are better than one general purpose interface,Design Principles,组合复用原则（Composite Reuse Principle）尽可能地使用多态的对象组合而非继承（来实现复用）favor olymorphic composition of objects over inheritance,abstract class AbstractExampleDoc
18、ument/skip some code.public void output(Example structure)if(null!=structure)this.format(structure);protected void format(Example structure);,class DefaultExampleDocument/skip some code.public void output(Example structure)ExampleFormatter formatter=(ExampleFormatter)manager.lookup(Roles.FORMATTER);
19、if(null!=structure)formatter.format(structure);,Design Principles,所知最少原则（Principle of Least Knowledge）一个类的操作实现中，只应调用下列对象的操作：它自己、作为参数传入的对象、它创建的对象、它包含的对象for an operation on a class,only operations on the following objects should be called:itself,its parameters,object it creates,or its contained instan
20、ce objects,只与你直接的朋友们通信不要跟“陌生人”说话每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位,Package Cohesion Principles,发布与复用等价原则（Release Reuse Equivalency Principle）软件复用的粒度与发布包等价 the granule of reuse is the granule of release共同封闭原则（Common Closure Principle）一道发生变更的类应当属于同一个包 classes that change together,belong togeth
21、er共同复用原则（Common Reuse Principle）那些不被一起复用的类不应当分组到同一个包中 classes that arent reused together should not be grouped together,Package Coupling Principles,无循环的依赖原则（Acyclic Dependencies Principle）包与包之间的依赖关系不能造成循环the dependencies between packages must not form cycles稳定依赖原则（Stable Dependencies Principle）包依赖的方向应当指向其它更稳定的depend in the direction of stability稳定抽象原则（Stable Abstractions Principle）系统中最稳定的包应当是抽象包stable package should be abstract,
