软件及架构设计中，充满了各种概念和定义，我对这些概念和定义的理解经历了三个阶段：

第一阶段，推崇阶段

推崇各种概念，并希望将这些概念运用到实际项目中；

当年学习 DDD 时，对领域建模中定义的各种概念十分推崇，迫切希望将这些概念落地到实际项目。我的技术方案里充斥着各种战略战术设计、子域划分、聚合根、值对象、实体，虽然没有实施统一语言，只是落地了 DDD Lite，但仍感觉很充实；

当然不排除里面也有一定的虚荣因素，毕竟谈论一些看似高大上的概念，在一定程度上确实能掌握话语权和解释权，进而产生一种莫名的优越感。

这个阶段充其量只是模仿，DDD 中充斥着大量概念，除非团队内部已经普及了 DDD 的基础，否则谈论这些概念只能增加沟通成本。

第二阶段，质疑阶段

当周围的人都开始谈论一些新奇的概念时，我逐渐发现，这些概念其实并无助于解决问题，反而增加了沟通成本，本来能用通俗语言描述清楚的东西，套上一层概念，反而要先理解概念的具体指代。

我产生了这种想法：人们高谈阔论这些概念的时候，无非是为了秀；真正理解背后原理的人，无需把这些东西包装成高大上的概念，应该能用通俗易懂的语言描述清晰，且符合逻辑。

后来我学习了 UNIX 系统的一些设计原则，发现很多理念都是相通的，这更加强了我的认识：逻辑 > 概念。

第三阶段，实用阶段

现在回想起来，第二阶段相当于从一个极端走向了另一个极端：从硬套概念转向了质疑概念。

计算机技术作为一个工科，倡导在做中学，即 先 know how，再 know why，找到一个自己信服的权威，模仿、学习、思考，才能成长：在学生阶段，这个权威就是教课书；在职场阶段，这个权威可能是某个领域内顶尖厂商的最佳实践，或者某一本有前瞻性的权威著作。

权威著作，我首推 UNIX，毕竟有什么系统能比操作系统还复杂呢？但是 UNIX 中也会定义各种概念，比如讨论复杂度管理时，定义了 “本质复杂度”、“选择复杂度” 和 “偶然复杂度”，这些概念不难理解，但只要定义了基础概念，问题域就明确了，大家在一些基础概念上达成共识，后续在讨论时就不会陷入问题模糊不清的境地。

比如，Emacs 复杂又庞大，但却很成功，它的成功是否挑战了 UNIX 小而美的设计哲学？讨论这个问题前，我们得先看它复杂在哪，哪些复杂度是不可避免的，哪些是由于增加功能而引入的，哪些是接口设计不够正交而导致的，这三个问题明显不属于同一类别，当我们在讨论复杂度时，我们到底在讨论哪种复杂度，到了这个时候，通过引入简单的概念来分类问题，无疑降低了思考的复杂度。

我的理解是，当问题域比较复杂时，先将问题域做简单划分，并定义简单可理解的概念，这样复杂的问题域就有了层次感，更利于聚焦核心问题，我将这种方法称之为 “逻辑复杂度的管理”，你看，这也定义了一个概念。不过，我自始至终都反对那种故弄玄虚的概念，这种概念除了把人绕晕，没有任何实际意义。