DDD-复杂问题解决之道

上个星期在团队内部进行了关于DDD的分享,分享链接:http://slides.com/fengchen/ddd-tackling-complex-problem#/

分享的过程中发现还是有很多小伙伴对DDD不太了解,或者一知半解。DDD其实不是一个新的技术,实际上距离Eric Evans出版《Domain Driven Design》已经12年了。与其说DDD是一门编程技术,我更愿意将它称之为软件开发方法。我发现国内的技术分享两级分化比较严重,要么太过高大上——关于架构、新技术之类,要么太底层——关于数据库优化、底层性能优化之类,但很少有人来讲中间的那一层——软件编程方法。

在我看来,一个新人要成长为技术大牛,都要经历下面三个阶段:

1. Make It Work (1~2 年)

刚刚踏入职场的新手程序员往往处于这个阶段,他们首要的工作是要让系统能正常工作。出于工作的需要,他们开始了解语言、框架、数据库、缓存。如果在大公司的话,可能会更早的接触服务框架、中间件等。但是他们的主要工作还是实现业务需求,对代码的质量没有过多的要求。有时候可能感觉到现在的写法可能不太好,但是又不知道怎么去组织代码才能让它们看上去更舒服,经常会刚到迷茫,好像刚工作一年就看到了未来十年的影子,这是十分令人沮丧的。这个阶段一般会持续1~2年。

2. Write better code (3~5 年)

这个阶段是新手程序员向老司机转变的一个时机。他们已经能独立完成常见的业务需求,并给出自己的意见。写出的代码不仅是为了完成功能,更多地是在寻找一种平衡的美。这种美很难言明,它是介于现实逻辑和代码组织的一种完美结合。正好我也处于这个阶段,我会有时因为一次完美的解耦而欣喜,也会因为业务的妥协而忧伤。在这个时期,我在寻找一种“术”,一种能随心所欲驾驭代码的术。我开始了解到OO技术的精妙,开始理解设计模式的妙用,学着掌控整个项目的发展,只为达到软件的最高境界——“可复用”。这个阶段肯能持续时间很长,因为我们要细细去品味优秀代码的味道并为己所用,这需要时间的沉淀。

3. Create suitable architect (5年 ~ )

当你能随心所欲的操纵代码时,你就会去寻找你还未涉及的阶段。这个阶段可能会产生多种分化,你可能会对项目的整体架构产生兴趣而走上架构师的道路,也可能对某些专有技术情有独钟而成为某一方面的技术专家。不论后面的发展方向如何,此时代码对你已经不是问题了,而成为了你的“工具”。国内的技术分享往往也集中在这个层面。好的架构往往有着相似的部分,但是每个架构又有它独有的业务背景,你需要剥离其中的业务部分,找出能为自己的项目有用的设计。没有完美的架构,只有最合适的架构,任何现实的架构都充满着妥协和折中。这个阶段持续时间可能更长,你也需要机缘能参与几个重大项目的架构设计。

说白了,软件开发还是一门需要经验的行业。我并不太相信天才的存在,因为没有长时间浸泡在代码之中项目之中,你是很难理解代码和业务的关系的,这需要大量的时间。现在“新技术”层出不穷,我的建议是,在没有成为真正的架构师之前,不要盲目的追逐这些“新技术”,这只会耗费你大量的精力。

言归正传,我认为DDD是一门教你Write better code的软件开发方法。就算你是底层的研发人员,我相信你也会从中收益。如果你是一名业务程序员(80%的都是),为什么不多花一些时间去真正理解你的业务呢?不要再去追逐那些“新技术”,多去思考一下我的代码该如何解耦、业务如何切分、代码怎么写才能更好的复用。如果你坚持这么做,我相信不出两年你对技术和业务的理解会发生质变。

学习DDD其实还是有一定的曲线的,如果你的团队中已经有人尝试过DDD了不妨向他取经,因为DDD的精髓更多的在于编程的思想,而不在于具体的代码。后期我会分享一些关于DDD、OO、Microservice方面的心得,如果你有这方面的心得和困惑也可以与我交流,分享是技术人成长的很重要的途径。

近期,我换了工作,加入了网易蜂巢团队。以前上研究生的时候就搞云计算,想不到时隔两年之后,又加入了云计算的浪潮之中,也算是殊途同归。

坚持原创技术分享,您的支持将鼓励我继续创作!