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

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

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

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