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