领域驱动设计-认知篇

背景

本人从事程序员这份工作将进10个年头了，在这10年里接触了很多项目，有新建的项目，也有交接的项目，在维护这些项目的过程中，面临的主要问题总结一下就是业务流程梳理依赖代码和代码组织混乱难以梳理，这两个问题我想也是大多数软件行业共性的问题，很长一段时间我都在寻找解决这2个问题的方法，但基本没有效果，偶然的机会我看了Eric Evans的领域驱动设计这本书，深有感触，看到了希望，之后顺着这本书提出的DDD的思维方式，又拜读了阿里张建飞老师关于DDD的文章，至此踏上里DDD之路。（个人感觉是DDD国内最好的践行者，很多文章都让笔者产生共鸣，他们团队推出的COLA框架值得学习）

DDD的几个重要认知

统一语言（Ubiquitours Language）

团队在讨论业务需求的时候需要归纳总结形成统一的业务术语，并且输出业务核心词汇库，这个意识非常重要，我认为很多项目为什么业务规模扩大以后，难以言明其业务逻辑，很大程度上是因为团队里的多种角色对业务都有自己的理解，很多理解其实存在偏差但是相互之间无法认识到，就这样带着偏差做完了项目，后期跌代的时候，我发现了一个很好笑的现象，就是后来者熟悉业务大多是靠口口相传，如果传承者离职那么只能靠自己去翻代码，通过很多命名奇葩，词不达意的类去了解业务，对于一个几万行的代码库，其梳理难度真的是难以言明（面对屎山，你不再是程序猿而是屎壳郎）。

统一的业务术语，大的方向上可以帮助我们建模，代码工程方面，可以指导我们切分模块，定义组件，甚至类和方法的命名，最终可以达到让我们核心业务领域无损的在代码中呈现，从而提升代码的可理解性。

面向对象（Object-Oriented）

这个行业里的人没有人不知道这个概念，做为比面向过程更先进的编程思想，感觉大多数程序猿都是说来头头是到，封装，继承，多态…
但是实际践行的时候就抛之脑后，不信，你看大多数代码，各类serviceImpl里充斥着面向过程式的业务逻辑实现，完全没有面向对象的思维，造成的后果就是每次迭代需求就是去一个几百行的方法里加几个if-else，代码可读性级差。

为什么大家都喜欢写面向过程式的代码呢？我通过跟很多同事进行沟通，发现是大家对oo的实践认识太少，讲白一点就是不知道怎么去实践，缺少方法论，而且工作中很少有优秀的oo实例可以学习，接触的大多是过程式的业务代码，慢慢只能随波逐流，长此以往，也就不在重视oo。这也是目前中国大多数程序员的通病，面向对象分析和对事物的抽象能力太差，大家把对技术的追求，放在对一些框架，中间件，分布式的学习，虽然这些很重要，但是怎么说呢，大部分程序员可能都是在做业务开发，其能力提升更应该放在怎么去做业务建模，去组织代码保证代码的可读性和可维护性。（我认为未来的趋势是云原生，低代码，由云去解决一些技术上的复杂问题，让开发人员更加聚焦在业务开发，所以学习DDD吧）

业务语义显性化

业务语义显性化要求我们不只是嘴上在讨论业务，提炼业务名词，更重要的目的是要求我们在技术实现阶段能使用这些达成共识的业务术语，让它们在我们的代码里显示出来，具体表现在各个模块的划分，组件的区分，类，方法，甚至变量的命名。

一切都是为了让代码更容易被理解，让我们组织的代码可以像读文章一样通俗易懂，最终达到减少代码复杂度的目的。

分离业务逻辑和技术细节

业务和技术明明是2个不同维度的，为什么在我们写的业务代码行间里夹杂着很多非业务的代码，这往往会打断阅读者大脑思维的连贯性，导致无法快速的理解业务流程。

技术细节是什么？比如我们用到的数据库，缓存，spring框架，rpc框架等等。

所以我们应该追寻一种方式能够分离业务逻辑和技术细节，这里可以参考DDD里著名的六边形架构（再次推荐张建飞的COLA ）。

题外化：最近sass比较火，我在想今后的sass怎么收费？ 这里就需要有个大概的评判标准去定义一个软件项目，我突然想到是否可以通过一个项目的技术复杂度和业务复杂度去给一个项目评分：
o(软件项目)=o（业务复杂度）+o（技术复杂度）；其中业务复杂度可以从商业模式的新老，业务流程长短等角度去加权计算，技术复杂度可以从基础架构，规模，技术框架等去计算。