领域驱动设计(一)(DDD:Domain-Driven Design)

过去,系统分析和系统设计是分离的,这样的结果导致,需求分析的结果无法直接进行设计编程,而能进行编程运行的代码却扭曲需求,导致客户运行软件后,发现很多功能不是自己想要的,而且软件不能快速根据需求变化。

DDD打破了这种隔阂,提出了领域模型的概念,统一了分析和设计编程,使得软件能更灵活的跟随需求变化。

服务器后端发展的三个阶段:

  1. UI+DataBase的两层架构,这种面向数据库的架构(上图table module )没有灵活性
  2. UI+Service+DataBase的多层SOA架构,这种服务+表模型的架构易使服务变得囊肿,难于维护拓展,伸缩性能差
  3. DDD+SOA的事件驱动的CQRS读写分离架构,应付复杂业务逻辑,以聚合模型替代数据表模型,以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展

DDD革命性在于:领域模型准确反映了业务语言,而传统的J2EE或Spring+Hibernate等事务性编程模型只关心数据,这些数据对象除了简单的setter/getter方法外,没有任何业务方法,被比喻成失血模型。那么领域模型这种带有业务方法的充血模型到底好在哪呢?

以比赛Match为例,比赛有"开始"和“结束”等业务行为,但是传统经典的方式是将“开始”和结束行为放在比赛的服务service中,而不是放在比赛对象本身之中。

提倡充血模型,实际上就是让过去被肢解被黑crack的业务模型回归正常(回归正常是指,把行为放到比赛对象中,而不是比赛的服务service中)。使得看到领域模型代码,就看到业务需求,没有翻译没有转换,保证软件真正实现“拷贝不走样”。

DDD最大的好处是:接触到需求第一步就是考虑领域模型,而不是将其切割成数据和行为,然后数据用数据库实现,行为使用服务实现,最后造成需求的首肢分离。DDD让你首先考虑的是业务语言,而不是数据。重点不同导致编程的世界观不同。

你可能感兴趣的:(技术杂谈)