很多程序员都有这么一个梦想——自己写的代码，可以像诗一样优美；自己做的设计，能恰到好处，既不过度，也无不足。
这种带有一点洁癖的完美主义就像一把达摩克利斯之剑，仿佛时刻在提醒着：不能将就、不能妥协。完美主义的代价是会在很长时间里持续的迷茫和焦虑。
每每看到这些像面条一样缠绕在一起代码，都会令人感到气愤、懊恼和羞愧。
怎么办？一边是无止尽的业务需求，一边是补丁加补丁的业务代码，开发人员被夹在中间像一只困兽，向左走，还是向右走？方向在哪里？不明白为什么花了那么多时间来学习技术，可还是写不好代码；为什么花了这么多时间加班，还是应对不了复杂度。
代码精进之路
就像Robert C. Martin说的：“不管你们有多敬业，加多少班，在面对烂系统时，你任然会寸步难行，因为你大部分的精力不是在开发需求，而是在应对混乱。”
其实，造成软件复杂性的罪魁祸首主要来自以下因素：
● 软件的本质复杂性——《人月神话》的作者Fred Brooks曾说：“软件的复杂性是一个基本特征，而不是偶然如此”。因为问题域有其复杂性，而软件在实现过程中又有很大的灵活性和抽象性，导致软件具有天然的复杂属性。
● 缺少技艺——“写代码”作为一种技能，入门并不是很难，北大青鸟三个月就可以做到。但是要想像大师那样优雅的“写好代码”，则并不是一件容易的事。需要持续的学习和实践，很多的软件复杂性都是因为技艺缺乏而导致的随心所欲的复杂性。
● 糟糕的技术氛围——在一个技术团队中，如果技术管理者们只在乎分配给你的任务有没有实现，从来不关心代码的好坏，又怎能指望团队写出“干净的代码”。
● 教条——总认为有什么灵丹妙药，在不恰当的场景使用了不恰当的解决方案，造成了不必要的复杂。
● 妥协——开始向自己妥协，向产品经理妥协，向工期妥协，向技术债妥协，总能很多借口把设计糟糕、混乱丑陋的代码发布上线。
这些其实都是很多心有不甘的技术人员都有的问题，是很多技术人共同的痛。与其做一个困兽，不如主动出击，通过大量的学习、研究和实践去解决一系列麻烦。
中间变量
我们可以通过添加中间变量让代码变得更加自明，即将计算过程打散成多个步骤，并用有意义的变量名来命名中间变量，从而把隐藏的计算过程以显性化的方式表达出来。
例如，我们要通过Regex来获得字符串中的值，并放到map中。
用中间变量，可以写成如下形式：
中间变量的这种简单用法，显性地表达了第一个匹配组是key，第二个匹配组是value。只要把计算过程打散成一系列良好命名的中间值，不透明的语义自然会变得透明。
领域驱动
领域驱动设计关心的是业务中的领域划分（战略设计）和领域建模（战术设计），其开发过程不再以数据模型为起点，而是以领域模型为出发点，研发过程如下图所示。领域模型对应的是业务实体，在程序中主要表现为类、聚合根和值对象，它更加关注业务语义的显性化表达，而不是数据的存储和数据之间的关系。这是“领域驱动设计”和“数据驱动设计”之间显著的区别。
仍以上面的CRM为例。假如我们先不考虑数据模型，而是采用面向对象分析（Object Oriented Analysis，OOA）对这个场景进行领域建模，那么可以得到下图所示的领域模型。
可以看到，领域模型的描述更加贴近业务，一些重要的业务术语和概念没有丢失，更完整地表达了业务语义。即使是产品经理或者业务人员，也不难看懂这样的领域模型，甚至他们可以和技术人员一起参与到梳理领域模型和创建活动中来。
通过DDD的战略设计和战术设计，我们可以为问题域划分出合适的子域，并对域中的业务进行建模。下图是我们在实际工作中为CRM进行的领域战略设计。
