软件架构、领域驱动设计漫谈

说起企业开发软件架构一般分为事务脚本和领域驱动,在.net阵营中比较流行ActiveRecord和表模块架构,这两种和事务脚本本质是一样的,都是面向数据库开发。企业级应用日益复杂,面向数据库开发在前期开发会比较快。但就像是没有打地基的楼房一样不可靠,.net提供了一种把数据库表模型转换为领域模型的方法,这个比较搞笑,表模型是是数据模型是平面的,2维的,领域模型是业务模型,3维的,你可以把领域模型转为数据模型,但是无法倒转。软件解决的是领域的业务逻辑问题,而不是解决业务数据该怎么存储。在面向数据库的开发方式中,业务逻辑都写在应用层的Service中,对于每个用例,每个业务需求都一行一行的在Service中实现,这样每个Service就是平面的信息孤岛,大量代码重复,随着时间的推移维护成本上升,生产力下降,维护人员根本不愿意修改代码,项目或产品风险越来越大。为了避免这个问题,就要做好软件架构。

软件架构本质就是分离关注点,把系统分为几层,每一层都有自己的关注点,而领域层是核心关注点,是价值所在。其他层都是为领域层做支撑用的。领域模型就是业务本身,需求的变化直接导致模型变化,面对模型的驱动可以把业务的本质了然于胸,从容面对需求变化。领域模型是怎么得到的?我们在接触领域的一开始,只能在脑中抓到领域中的一些基本概念,这时候建立的是基本概念模型,是幼稚的,随着迭代对业务的不断了解,开始能抓中众多需求的本质,把模型抽象,把重要的业务规则从隐式的转化为显式的,去掉华而不实的模型和关联等等,不断的精炼模型,这样从浅模型得到深层模型。

通常领域层的代码只占整个系统中很少的一部分,但是价值却占很大比例。在实现领域代码时候,应该由水平最高的工程师来实现,对这部分代码进行精心测试,因为领域模型就是POJO的,不依赖任何框架,所以比其他层的代码都容易测试。在代码实现的时候,是对业务细节也是更深的理解过程,这时候也可能对业务模型有新的认识,所以在代码实现的过程中领域模型也在深化。领域模型实现不应依赖任何技术,不依赖其它层,不会因为你是否用了spring或者ejb、hibernate而对领域模型做出改变,领域模型的改变的因素只能是业务,而不是技术。在领域模型驱动的开发过程中,要随时警惕其他层对领域层的腐蚀。领域驱动不是一条容易走的路,但是你走熟练了,这条路会带给你不断的惊喜。

相关推荐