保持模型的驱动性
好的开始未必是成功的一半,模型首要是一致性,条款统一没有矛盾。理想的大的企业模型是不现实的,如果我们一直想实现大而全的理想模型,我们将什么也做不成,现实的模型是,将大的模型设计成较小的部分,每个小模型要却来越相对独立,模型的划分没有技巧,只能把相关联并且能形成自然概念的因素放到一个模型里,并且模型之间要定义清晰的边界,模型间关系也应该要精确定义。
1. 界定的上下文
定义模型的范围,画出它的上下文边界,然后尽可能保持模型的一致性。不能因外界的因素影响,我们不能在不同模型间传递对象,也不能在没有边界的情况下,自由地激活行为。这里的上下文,说的很多都是边界。
2. 持续集成
模型不是一开始就被完全定义,先被创建,然后基于对领域新的发现和来自开发过程的反馈等继续完善,基于模型中概念的集成,然后通过测试实现,任何不完整的模型在实现过程中都将被检测出来,通过不断的持续集成,将新增的部分和模型原来配合起来。
3. 上下文映射 (Context Map)
是指抽象出不同界定上下文和它们之间关系的文档,上下文可以作为团队组织的基础, 上下文映射应该写成文档,说明模型之间关系,各层次之间关系。
4. 共享内核 (Shared Kernel)
多个团队如果出现重复性部分,并且令模块十分笨拙,并且无法持续化集成,并且进度缓慢的时候,应该采取共享内核的方式,这种方式修改的时候应该十分小心。
5. 客户供应商 (Customer-Supplier)
如果两个系统之间关系特殊的时候,例如一个严重依赖另一个,并且上下文不同,好比Web商店中“购物系统”与“报表系统”,都是用同一个数据库,但是对用户行为信息,所需要各有不同,这种情况应该使用一方为消费者,一方为供应商的方式交谈,“购物系统”因为供应商,因为用户的行为是通过购物产生的,“报表系统”应为客户,因为它只能调用数据库中数据,这样就可以“报表系统”小组向 “购物系统”小组提出需求,双方协调沟通进行。并且双方都增加测试集合,来保证接口的稳定性。
6. 顺从者
如果客户供应商关系是可行是很好的结果,但是实际情况有很多时候,由于供应商来自很多客户的压力,很难很快实、按时完成客户的项目,这样客户必须选择其他方式来构建自己模型,一种方式是自己实现,还有一种方式是供应商团队的模型很好,可以拿过直接使用,但是前提条件是不能修改模型代码,例如供应商提供组件,客户在组件基础上构建自己应用。
7. 防崩溃层
我们经常碰见所创建的应用与需要和遗留软件,或者和其他独立应用相互交互的情况,由于遗留软件没有使用领域模型技术构建,所以对其使用的模型无法理解,甚至模型模糊不清,所以我们只有建立一个中间层来处理和旧应用的交互,并且也是旧系统的需求。
每一个服务都有一个对应的Façade,对每一个Façade 增加一个 适配器,因为这样会使我们无法清晰的处理繁多功能,如果外部系统复杂,那么在增加一个额外的Façade这样会简化适配器的协议,将它和其他系统分离出来。
8. 独立方法
如果整合难度很大,不值得去做,那么就应该考虑独立方法。独立方法模式,适合企业的应用可由几个较小的应用组成,而且从建模的角度来看,彼此有很少或者没有相同之处的情况。它有自己的需求,从建模和设计的观点来看,它可以由独立实现和独立模型来完成。这种方式应该慎重采用。
9. 开发主机服务
集成两个子系统时,通常它们之间创建一个转换层,当一个系统集成过多子系统时,为每个子系统定制一个转换器会将使整个团队陷入困境,会越来越多的代码维护工作。解决这个问题的办法是,将外部子系统看作服务提供者,所有的子系统访问这个服务,我们这时就不需要转换层了,定义一个能以服务的形式访问你子系统的协议,使的所有想与你集成的人都能获得它,有特殊需求,采用增加协议。例如http协议访问网站,应该就是服务的方式。
10. 精炼
一定要专注核心模型的开发,不要被其他模型所牵连,如果过多精力在其它模型上,那么就与和行业务逻辑的关注想背离了,核心领域的研究和开发不是一朝一夕能完成,需要不断的提炼。一定要关注核心领域模型,就好比软件“心脏”一样。
对于普通子域的实现:
- 购买现成的方案
- 外包:将设计和实现交给其他团队完成,一定要和子域通信接口需要事先定义好。并且要保持沟通。
- 以有模型:使用一个已经有的模型。
- 自己实现模型,这个方案好,但是需要付出额外的精力和金钱。
备注:每个团队都工作于自己的模型,最好每个人都能整个理解模型
分享到:
相关推荐
DDD领域驱动设计
Eric Evans 《领域驱动设计》总结之作,领域驱动设计精简版 全新修订(2014)
模型驱动--MDA简介。 简要介绍模型驱动的开发技术的。
领域驱动设计精简版 领域驱动设计精简版 领域驱动设计精简版
软件系统分析与设计-精简版.pdf
u-boot中的i2c驱动模型----visionfive开发板
领域驱动设计精简版领域驱动设计精简版领域驱动设计精简版
场景模型驱动测试-QECon深圳站2021年全球软件质量&效能大会
……本书是Eric Evans的《领域驱动模型》一书的精简版,让你在短时间内理解领域驱动设计的内容。这本书没有介绍任何新的概念,它只是概要总结了领域驱动设计的本质,抽取了Eric Evans原书中关于这一主题的大部分内容...
领域模型使开发人员可以表达丰富的软件功能需求,由此实现的软件可以满足用户真正的需要,因此被公认为是软件设计的关键所在,其重要性显而易见。但讲述如何将领域模型用于软件开发过程的优秀实用资料却不多见。本书...
microsoft windows驱动程序模型设计2nd-随书光盘2
领域驱动设计就是用来处理这些高度复杂领域的理想和途径,使得领域本身成为项目关注的焦点,从而达到维护能深刻反映领域的软件模型的目的。这个理想在Eric Evans的《领域驱动设计》一书中变成现实,Eric自己有着20...
windows驱动程序模型设计-光盘1和2
--真正的模型驱动开发。目前的建模工具很多,不过个人的观点来看,基本都跑偏了。没办法真正应用模型驱动来有效开发。废话少说。下面的就是MDA(KAYA)建模工具。左侧是需要用到的元素,简单说来包括1.Product(产品...
件是一种被创建用来帮助我们处理现代生活中复杂问题的工具,它 只是到达目的的一种方法,而这个目的通常就是非常实际和真实的 事情。比如,我们使用软件控制空中交通,这就和我们日常的生活 有直接的联系。...
《领域驱动设计》精简版,对《领域驱动设计》的总结,前几章翻译不错,后面就不行了。
领域模型使开发人员可以表达丰富的软件功能需求,由此实现的软件可以满足用户真正的需要,因此被公认为是软件设计的关键所在,其重要性显而易见。但讲述如何将领域模型用于软件开发过程的优秀实用资料却不多见。本书...
本书的目的是专注介绍领域驱动设计的基础知识。