参加峰会“金点子”的材料

时间:2022-08-31 14:41:45
记录一下,9月份参加研发峰会时的材料。写得不好,而且思想也并不成熟。大致内容如下(EXCEL中直接粘过来的,比较乱):
类别 任务名称 背景介绍 目的
(不超过三个)
目标(smart_c) 关键策略 选定方案 策略、方案、计划制定人 实施负责人 协作人 督导人
考评人
时间 行动计划关键里程碑 成败攸关因素 管理三问
开发 设计:领域建模解决方案模式 1.业务与代码实现脱离:一般情况下,在进行领域建模时,都会使用图形化的建模工具。在追求开发效率的今天,这种纯建模方式由于它的代码无关性,只能用于对领域内模型进行大体的关系层面的描述,而不会特别详细。这样会导致后期的具体开发会和设计相脱节。而有些直接使用类进行建模或使用数据库建模的方法,也面临着相似的问题,即二者相脱离。
2.不够纯净的模型代码:在代码层面,一般的业务模型类会包含太多的非业务信息。如直接映射数据库字段而来的属性、如表示层显示的信息。这些非业务的信息附加在这些它的上面,会使得业务模型类过于庞大。而基于它的分析、设计、实现,都会不可避免地更加复杂。(如,在设计业务类的时候,会不自然地去考虑数据映射等问题。)
3.不易满足设计思想:领域建模得到的业务模型类,应该是基于OO思想的。可是单使用目前的各种ORM框架,是不可能实现任意的映射(因为里面很可能包含我们自己的映射规则)。
1.在“纯净的领域建模环境”下建立“纯净的领域模型”。
2.领域建模得到的业务模型,应该是完全符合面向对象思维的,应该是可随意设计的。并且应该能够精准地描述业务,应该是可以直接指导开发的。
3.模型到代码实现的快速转换。相对原来的实现,不会添加过多的工作量。
1.构建的每一个模型,都是纯净的,不能拥有业务以外的内容。这包含模型的所有属性和方法。
2.构建的模型,应该精确到每一个属性。
3.模型的设计,满足三大面向对象原则:封装、继承、多态。可在不考虑其它因素的情况下,随意设计以达到业务要求。
4.模型的构建,时限必须比纯图形方式更快。(由于项目的大小不同,这个时限需要按需界定。)
5.模型建立完成后,基于这些模型的代码实现较一般开发方式相比,额外需要的开发时间不能超过10%。
1.使用“代码即设计”的方案。(原因:设计直接就是代码,无需转换。OO语言的代码,直接支持可使用OO的原则。文本文件,编辑方式灵活,可迅速构建。)
2.基于interface code建模。(原因:足够抽象,只关心业务规则。相对只进行关系建模,更加具体,可清楚地定义每一个属性,方法,关系。)
3.模型代码实现可支持使用ORM框架等。(原因:支持一般的开发模式。)
4.代码生成 + 通用框架。(原因:减少开发时间。这步主要是生成一般性的代码,构建通用的框架。)
1.在需求明确后,使用interface code描述业务模型的属性和方法。所有的code都应该确定下来。具体到每一个属性的名字、类型等。(简单文本适合于快速开发。)
2.(可复用的)为了辅助第一个步骤,可以开发一个图形化的模型查看工具(对模型只读)。这个工具不但可以查看模型是否构建有较大的问题,更加有用的是,方便和其它人员的沟通,包括开发人员、需求分析人员、业务专家等。(图形化的方式会比较有利于沟通。)
3.(可复用的)代码生成器 + 通用框架。代码生成一般会包含SQL建表语句。当然,视具体开发情况而定,也需要为不同的模型实现生成不同的代码:如对应Hibernate用一套,对应POJO用一套……同样的,框架也分为两部分:抽象通用的一部分和具体使用某ORM框架的一部分。
4.定制开发。以第一步的interface为界限,一分为二。上层人员基于这些业务模型,直接组织业务“流”逻辑,十分方便业务维护。下层为模型实现具体的类,需要考虑以下内容:数据库的设计、选定适应需要的ORM模型(或者不使用)、实现映射模型中ORM框架未实现的特殊映射规则。一个中小型项目中,这个工作的实施往往只需要一到二个精通ORM的人即可。
胡庆访 胡庆访 胡庆访 胡庆访 2010、2 得到:通用框架、代码生成器 通用度的抽象。(需要更多小型项目的测试) 1.承办人目标明确(承办人能准确复述): (是)、(否)
2.承办人的能力(与目标要求的匹配度): (高)、(需要指导)、(需要协助)
3.承办人的积极性(如何进行有效激励): (高)、(一般)、(低)
2010、3 得到:模型查看工具 interface code中通用定义规则的抽象。
具体项目开始时间+半月 得到:业务模型 理解需求。
具体项目开始时间+一个半月 得到:业务模型的实现代码 精通ORM。

 

具体的文件:

http://files.cnblogs.com/zgynhqf/DDD_Pattern.rar

里面一个是五环表,一个是示例代码。