上个星期在团队内部进行了关于DDD的分享，分享链接：http://slides.com/michael-j/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方面的心得，如果你有这方面的心得和困惑也可以与我交流，分享是技术人成长的很重要的途径。
近期，我换了工作，加入了网易蜂巢团队。以前上研究生的时候就搞云计算，想不到时隔两年之后，又加入了云计算的浪潮之中，也算是殊途同归。
