规矩礼仪，务必先尽守之，然后破之，离之，然皆不可忘本矣。

理解守破离

“守破离”最初起源于日本剑道，是一种学习剑道的方法，后来，这种方法被发展到了整个日本武术界，乃至其他各个行业，成为一种崇高的工作精神和态度，也是“工匠精神”的一个核心。

在理解了守破离之后，你会发现，我们的学习都要经历守——破——离三个阶段。所谓“守”，就是最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界；“破”是在基础熟练后，试着突破原有规范让自己得到更高层次的进化；而“离”顾名思义，就是离开的意思，是指在更高层次得到新的认识并总结，创造新境界。“守破离”从低到高，依次体现了我们学习必须要经历的三重境界。

“守破离”对应到我们华为的文化，就是“先僵化——再优化——再固化”

对于程序员的学习成长来说，“守破离“显得尤为重要。因为软件设计是一个门槛非常高的行业，需要一个长时间“守“的过程，通常来说，作为一个计算机科班学生，至少要在学校系统的学习4年的基础理论知识，如果是硕士或博士，这个时间还要更长。这些基础课程包括《数据结构》《算法》《计算机体系结构》《软件工程》《面向对象设计》《编译原理》《计算机网络》《数据库》等等。这些还只是理论知识，进入职场之后，还需要至少3年的实践，才会慢慢有一些感觉。我还记得，我2007年才入职场的时候，接手了一个银行单据处理系统，混乱的代码着实让人难受，作为一个职场小白，我找来一本设计模式的入门书《Head First Design Pattern》，一边看书，一边学着书上的样式重构代码，每天工作到凌晨1、2点，花了一个月时间，把几万行的代码重写了一遍。现在回头来看，虽然当时付出了巨大的努力，但只是有样学样，重构后的系统虽然有一些改观，但根本谈不上优雅。

在之后的10年里，类似这样的学习、实践、再学习、再实践的的过程，我“守”了10年，直到2017年，我才对技术有一些不一样的感悟，开始有一些我自己的软件设计的理解，形成了自己方法论。也就是说，从2000年上大学开始，到2017年，我花了整整17年，才勉强成为一个软件设计的熟练工。这不禁让我想起秋山木工的学徒，他们要每天5点起床跑步、打扫卫生，晚上工作到10点下班，如此往复，经过8年不间断的历练才能出师，100个人里面，能坚持到出师的不过7、8个人而已。“守”不容易，需要坚持，需要长期主义，我很庆幸我在阿里巴巴做技术管理的7年，一直没有放弃对技术匠艺的追求，这才有了后来的突破。

得益于近20年的持续积累，从2018年起，我开始尝试一些突“破”的事情，2018年我发布了现在被业界广泛使用的COLA架构；2019年，我出版了我的第一本书《代码精进之路》，我本人也凭借这本书获得当年人民邮电出版社的最佳作者，19年当我去北京出差，顺便参观人邮的时候，发现电梯里有这本书的海报，很是欣慰；2022年，出版了我的第二本书《程序员的底层思维》。在这期间，我也是连续三年阿里ATA（Alibaba Tech Academy，阿里内部技术社区）的最佳作者。这些成绩和之前近20年的坚“守”是分不开的。

我对DDD的守破离

然而到底要如何“守破离”呢？接下来，我用我学习和使用DDD的心路历程，给大家讲解一下如何进行“守破离”。

坚守

“我们不会用DDD，关于DDD，我还没有看到一个成功的案例。再说现在都是敏捷，我们也不需要过重的设计”。2015年，当我的下属第一次建议我们在团队尝试DDD的时候，这是我的真实回答。

事实的情况是我当时的判断是武断的，因为时间又过去一年，我们做事的方式没变，敏捷也没有像预期的那样涌现出好的设计，系统依然复杂。为了寻找出路，我开始有点不情愿的翻开Eric Evans的《领域驱动设计》，这一打开不是打开了新的世界，而是弄翻了潘多拉魔盒，一堆概念扑面而来。读第一遍的时候，光这些概念（新名词）都没有记住。

没办法，看一遍不行，就两遍，两遍不行，就三遍。三遍之后，终于大概知道Ubiquitous Language、Bounded Context、Context Mapping、Domain、Domain Service、Domain Events、Repository、Entity、Aggregate Root、Value Object等这些概念是啥意思了。

在这期间，我除了看书，也不忘向过来人请教。当时听说辉子（张群辉，现在也在华为）非常精通DDD，他当时在阿里的盒马，我就专门从杭州跑到上海向他请教DDD工程落地的事情，我还清楚的记得他当时打开代码仓给我讲解代码结构的画面，这也是我第一次看到一个鲜活的使用了DDD比传统的Transaction Script（事物脚本）方式要好的案例，这一次拜访，极大地增强了我使用DDD的信心。于是，从上海回来之后，我决定带领团队在项目中使用DDD。

我们实践落地的第一个项目是阿里巴巴的CRM系统，我们花了很多时间讨论边界、模型、聚合根，把原来三层架构换成有领域层的四层架构，我们小心翼翼的按照书本上的概念，做设计、写代码。从面上看，这的确是一个基于DDD思想的工程，有分层、有模型、有设计，但是落到具体代码细节的时候，可谓是千奇百怪，千疮百孔，问题很多。想必你已经知道了，我们的第一次DDD尝试并不美好。

“守”的过程就是这样的，你需要花很多的时间和精力去学习。对于软件来说，除了学习，实践更加重要，因为毕竟是应用学科，你需要把这些理论知识拿到项目中去实践，在这个过程中，犯错、踩坑基本上是一定会发生的，这也是我们在“守”、也就是在“僵化”的过程中必须要付出的代价。

突破

有了前面学习的过程和踩坑的经验，我开始反思光有DDD的理论不行，问题都出现在工程落地的细节中。于是，在接下来的3年里，通过项目实践，不断的犯错，不断的调整。我总结出了一套切实可行的DDD工程落地的方法论。概括来说这个方法论就是：自上而下的结构化分解+自下而上的抽象建模，循序渐进的沉淀领域能力。在我加入华为之后，使用这套方法论，我已经在GTS、华为云、数通、招商银行等多个部门中，成功落地多个项目，取得了非常好的效果。具体内容我也写成了文章：《跨越DDD理论到落地的鸿沟》。在2022年ICT软件大会上，我也发表了《跨越DDD从理论到落地的鸿沟》同名主题演讲，截止目前，该微课在iLearning上还是排在Top1并且100%好评的课程，足以证明大家对这套方法论的认可。

之所以能形成这套方法论，正是因为我在实践DDD的过程中，不断摸索、不断反思、不断总结，不拘泥于具体规则的条条框框，在DDD核心理念的基础上，尝试找到控制复杂度的有效方法。这个方法论完全是我的独创，实际上，我的第二本书《程序员的底层思维》也是基于这个方法论中涉及到的结构化思维和抽象思维展开而来。我想，这应该算是对DDD的升华和“突破”了吧。

离开

但是真正的“离”开，还是发生在最近的事情，就像Neal Ford说的“Everything in software is a trade-off”,我也开始有同样的感悟，在软件领域，虽然有很多的模式和原则可以参考，但是永远没有“银弹”，每一次的工程落地都要根据当时的环境小心权衡。比如我们都知道重复代码是典型的代码坏味道，但即使是这样的金科玉律，也有被打破的时候，因为所有的代码复用都会引入耦合，为了解耦，有时候Repeat比Resuse要更好。我把这些感悟写成了一篇文章《软件设计的中庸之道》。

对DDD也是如此，相爱相杀了这么久，也是时间说“离开”了。今年我在主导ICT软件设计培训（Java），截止目前，已经交付了4场训战课程。在每次课程的一开始，我都会跟学员们强调，这门课程不是DDD课程，但是会涉及到DDD的一些核心概念。言下之意是说，我已经不再需要DDD这个标签，而是升华到一个更高的层次，在这个层次，我不在乎你是否有聚合根，是否有值对象...... 我只在乎你当前的做法是否控制了软件的复杂度，提升了代码的可读性和系统的可维护性。

这的确是当前我对DDD的真实感受，即DDD不是概念的教条，而是一种新的协作方式、一种新的思维方式。

• 新的协作方式是指，在统一语言（Ubiquitous Language）的牵引下，定义概念，对齐语言，让业务人员和技术人员可以更好的协作。同时，语言作为桥梁，也是保证软件设计和实现一致性的关键所在。

• 新的思维方式是指，我们如何从以前以数据为中心的思考方式，转变到以Domain（领域）为核心的思考方式。不可否认，数据模型和领域模型在大部分时候有一定的相似性。但是二者的职责完全不一样，数据模型关注的是数据存储，而领域模型关注的是领域概念、领域能力和业务逻辑。

基于这样的认知，这当然已经不再是传统意义上的DDD。如果说这是“离开”的话，更准确的说法应该是形“离”，神不“离”。即核心理念还是基于DDD的思想，但已经脱离了对形式一致性的追求。实际上，在软件的世界里，根本就没有什么固定范式，正如我在《软件设计的中庸之道》中所说，软件设计无其他，唯有中庸之道，都是权衡。

不过，有一点需要强调，大家不要被我这轻描淡写的“离”所迷惑，认为DDD也没什么嘛！就这么点玩意而已。认为可以绕过那些复杂的概念，犯错的过程，看看我的文章，听听我的演讲就能轻松搞定DDD。我的确可以帮助大家少走弯路，但是你自己要下的功夫，要犯的错，要经历的困惑，要熬的夜一样也不能少。

写在最后

最后，我想说，任何的学习都要经历这样的“守破离”的过程。你必须要经过漫长的有样学样的“守”，要熬的住，就像张大千，他的前半生基本都是在临摹，正是得益于长时间的临摹，这才成就了一代大师。日本的工匠精神也是如此，很多人一辈子就煮一碗饭，做一个寿司，做一个木工......最后从中悟出道来，在平凡中成就了伟大。软件设计作为纯抽象的智力活动，需要付出的努力要更大，所以，首先我们要能“守”住，不要过早的放弃，认为35岁还不能做管理，就没有希望了。很多优秀的软件人才，过早的走向“管理岗”，丢失了对技术的持续打磨和精进，是一件非常可惜的事情。我自己也是“守”了17年，才拨云见日，稍微摸到些软件的门道。没有这样的坚“守”，就没有后来的“破”和“离”。