登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评论 > 正文

领域驱动设计(DDD)高手养成记

2018-12-14 14:45    it168网站 原创  作者: 老鱼 编辑: 覃里

  摘要:开发出一款基于业务的高质量软件产品,一直是架构师与软件开发工程师为之努力的目标,之所以说是努力的目标,是因为这其中存在众多的难题。

  比如:如何将业务需求准确的转化为软件设计?如何能让团队人员在开发时能专注于业务,而不是技术本身?如何解决跨部门间语言沟通问题,如开发与业务之间的沟通障碍?如何解决软件系统不会随着时间推移而慢慢腐烂的问题等等……

  为了解决这一系列的问题,15年前,Eric Evans提出了一个行之有效的方法论,即领域驱动设计(Domain Driven Design,简称DDD),Eric Evans也因此享誉全球IT圈。

  略微让人遗憾的是,对于DDD,国内了解的人却并不多,我们也甚少听闻,业界有宣称应用了DDD原则的项目和软件。

  没有掌握DDD的人,抱怨这一技术过于晦涩、在现实中根本无处着手。而掌握了它的人却觉得没那么难,不过是一种很自然的设计方法选择。

  DDD对架构师和软件开发工程师意味着什么?对企业又意味着什么?我们应该如何正确的理解DDD并落地使用它?DDD高手是如何养成的?

  近日,由ThoughtWorks发起的第二届领域驱动设计中国峰会(2018 DDD China Conference)在北京召开,笔者有幸采访到2位DDD的实践型专家,他们分别是民航信息技术总监,领域驱动设计中国峰会话题出品⼈张逸,ThoughtWorks高级咨询师,周宇刚。一起来看他们的经验之谈。

  如何学习并落地使用DDD?

  对于98年大学毕业的张逸来说,2006年的他,已经是一名有着丰富编程经验的老程序员了,就在那年,他通过Eric Evans的《领域驱动设计》一书,第一次接触到DDD。

  “那个时候,学习DDD主要靠看书,外加自己琢磨,因为,没有人教,也没有氛围。”张逸说。

  与此同时,他也开始在工作中逐渐尝试使用DDD,因为Eric一书晦涩难懂,并不好理解,因此,在实践的过程中,很多时候他都是一知半解的在做,就这样持续不断的实践了10多年。

  “类似航延结算、协同决策等偏业务的系统,我们就会尝试采用DDD去改进系统架构,改进代码质量,但过程并不顺利,走的磕磕绊绊的。有时间周期问题,还有团队成员能力问题。” 张逸说。

  如今回过头来再看,一个项目,纯粹按DDD的方式去做的比较少,很多项目因为历史遗留问题,再加上团队在DDD理解上的一些分歧,导致很难有项目完全按照DDD去做,但会引入一些DDD思想。当找不到答案时,其实还是从设计的本质去看,甭管是否符合Eric Evans书中所介绍的东西。

  周宇刚接触DDD的时间是 2009年,比张逸略晚,很难想象他是一个做过导游的程序员,周宇刚学习DDD的原因是在日常编程工作中遇到很多挑战,比如,一个预订流程,面向对象应该如何去做?对象是什么?怎么协作?

  直到有一次,无意中看到了Eric的书,仅看到战术设计的前半部分,就让他如获至宝。为了进一步学习DDD,他还特意去国外网站Stack Overflow上注册了个账号,就是为了去看看别人是如何学的。其实,跑到国外网站去看也是无奈之举,因为搜遍了国内网站,发现根本没人在聊DDD。

  事实上,书的后半部分战略设计甚至还没来得及看,他就已经等不及了,要在自己项目中去实践。

  作为Team Leader,他工作中有较大的自主权,所以,比较容易的就在自己项目中开始尝试,但过程是曲折的。“因为最初并不知道DDD到底是什么?一边要尝试去理解它,一边又要在自己项目中去实践”,周宇刚说。

  当书上的知识或别人的案例跟实际项目不是特别契合时,在实践的过程中应该怎么去积累自己的经验呢?周宇刚认为,要跳出这个领域去设计,因为,我们追求的不是用不用DDD,而是用了DDD能达到什么效果。

  如何正确理解DDD?

  为什么很多人会觉得DDD很难学?因为,它就是一个思想,一个方法。周宇刚说。

  开始,你以为DDD是一个面向对象的建模方法,能告诉你企业应用架构该怎么做,慢慢的,你又会发现,它告诉你的是怎么识别问题,如企业应用中的问题,业务领域的问题,哪些应该拆开处理……

  事实上,DDD最初是一个综合软件系统分析和设计的面向对象建模方法,如今已经发展为一种针对大型复杂系统的领域建模与分析方法。

  张逸认为,要了解DDD,首先得弄清楚它的历史背景与来龙去脉。

  虽然,从Eric Evans出版那本划时代的著作《领域驱动设计》至今,已有差不多十五年时间,DDD也发生了一些变化,但Eric Evans为什么要提出DDD?这是学习DDD需要去了解的。

  2004年,Eric Evans提出DDD,刚好是面向对象设计大为流行之时,UML也是甚嚣尘上,但是,这个时间节点上,软件设计还有一个致命的问题,软件系统开发还是从数据库角度去进行。当然,这里面涉及多种原因的,也是需要了解的。

  原因一、当时的软件系统开发,并没有现在的多样性,系统操作的源头还是操作数据库,只是简单与复杂的区别。

  原因二、软件行业本身很像是一个软件作坊,依靠的是老代新的传承方式。而老人最早接触到的就是面向数据库的设计,所以,虽然已经有面向对象,但开发者的开发工作仍然是基于数据库驱动。

  因此,Eric Evans的书中就特别强调,如果采用面向数据库设计的思维去建模,很难去享受DDD带来的好处。张逸认为,要正确理解DDD的最关键的一点,是理解Domain Driven,并由此角度去驱动它,而这需要保证两点:

  一、在设计时,压根就不要去考虑技术实现,只考虑业务,只考虑domain。

  二、DDD不纯粹是一个软件开发方法,强调Domain,强调领域就要有沟通,一定要有协作,很多人之所以做DDD比较困难,甚至于做的不好,就是没有业务人员参与,基于业务的沟通机制是DDD最核心的。

  DDD对企业、架构师和开发者意味着什么?

  在周宇刚和张逸看来,DDD对企业有2个方面的价值,一是能帮助企业识别自身核心领域,决定企业资源的运用。二是能帮助企业优化团队组织结构与文化。

  周宇刚说,从价值导向看,DDD对于企业而言,是一种策略,能帮助企业识别自身核心领域,决定了企业资源怎样去运用,来支撑核心竞争力。比如核心领域,需要花大精力去做,非核心领域,可以采用更简单、更快速的方式去做,甚至直接采购成熟的软件套件。

  而张逸则就DDD对团队组织结构和文化的价值进行了阐述,他表示,很多时候并不是技术上的问题,而是团队组织结构和文化方面的问题。当然这不纯粹是DDD能推动的,还可以通过敏捷或者精益的方式。

  对架构师而言,DDD对架构师落地战略设计是会有帮助的,周宇刚说。因为,DDD解决跨部门间语言沟通问题,在业务、产品、开发之间建立领域通用语言以提高沟通效率。而对于开发者,DDD的作用更实际,能帮助开发者正确地开发所负责项目的代码。

  张逸认为,对架构师而言,DDD能帮助架构师确认系统、领域边界,边界确认好,即使里边有问题,只要边界是稳定的,那么,系统就不会受到太大影响。

  边界控制好,整体架构就会很清晰,把控也会更直观,这样的架构就不容易腐烂,现在的软件系统最大的问题,是随着时间推移它就会慢慢腐烂。而且把边界控制好,代码落到实现层面上也就相对容易。

  对于开发者,张逸认为DDD主要有两个层面价值:

  一、能够帮助开发者补充知识,不想当架构师的开发者不是一个好的开发者,开发者不能只满足于架构师分配的一亩三分地,也必须了解DDD知识。开发者如果只知道架构师要干嘛,却不知道架构师为什么要这么干,是很难提高的,这也不利于开发者去实现出来。

  二、一体化的知识结构,从DDD落地上说,因为DDD更偏向于业务,更希望从业务的角度去看,所以,DDD能更好地和开发者所掌握的一些最基本设计原则匹配起来。

关键字: DDD , 开发者 , 架构师
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部