今天看陶公子的文章有点感想。（文章链接： https://zhuanlan.zhihu.com/p/357411780 ）
在刘伟老师的《Java设计模式》一书中有这一段话：
通常认为，一个易于维护的系统就是复用率高的系统，而一个复用性较好的系统就是一个易于维护的系统。但实际上软件的可维护性(Maintainability)和可复用性(Reusability)是两个独立的目标。对于面向对象的软件系统设计来说，在支持可维护性的同时提高系统的可复用性是一个核心问题，面向对象设计原则正是为解决这个问题而诞生的。
知名软件大师RobertC.Martin认为，一个可维护性较低的软件设计通常由如下4个原因造成。
(1)过于僵硬(Rigidity)：很难在一个软件系统中添加一个新的功能，增加一个新的功能将涉及很多模块，造成系统改动较大。如在源代码中存在大量的硬编码(Hard Coding)，使得代码的灵活性很差，几乎所有的修改都要面向程序源代码进行。
(2)过于脆弱(Fragility)：与过于僵硬同时存在，修改已有系统时代码过于脆弱，对一个地方的修改会导致看上去没有关系的另一个地方发生故障。
(3)复用率低(Immobility)：复用是指一个软件的组成部分可以在同一个项目的不同地方甚至在不同的项目中重复使用。而复用率低表示很难重用这些现有的软件组成部分如类、方法、子系统等。即使是重用也只停留在简单的复制粘贴上，甚至根本没有办法重用，程序员宁愿不断重复编写一些已有的程序代码。
(4)黏度过高(Viscosity)：对系统进行改动时，有时候可以保存系统的原始设计意图和原始设计框架，有时候可以破坏原始意图和框架。前者对系统的扩展更有利，应该尽量按照前者来进行改动。如果采用后者比前者更容易，则称为系统的黏度过高，黏度过高将导致程序员采用错误的代码维护方案。
这里面指明了复用性与可维护性的关系。而当我们追求DRY的时候其实就是在追求更高的复用性。
过度的追求DRY，可能会破坏系统的可维护性。
让我们来试着以“夸张”的方式来分析一个问题：当我们追求DRY的时候静态代码检查、强制类型等已经成为了我们DRY的阻力。然后我们试着通过DSL的方式，隔离变化与不变。当DSL引入后我们如同释放了天性的孩子，可以自由的通过DSL组合业务逻辑。
然而业务逻辑是多样性且随着需求进行而增长的，所以我们DSL的复杂度会与需求的量会成一个正比。最后到某个阶段我们的DSL会变成了一个“脚本语言”，而我们的系统成为了这个“DSL脚本语言”的解释器。
看到这里有人会觉得这很高级啊。诚然我们实现了一套DSL脚本语言很值得“庆幸”。当我们把需求的多样性扩大到无穷大的时候，对DSL语言的灵活性也就要求无穷大。这样我们需要的不再是一门“DSL脚本语言”，而是一门真正的编程语言。
接下来让我们分析一下维护DSL我们将面临什么：
DSL过早腐化：由于我们所在环境，需求的成熟度完整性及程序员水平的参差不齐。当DSL还没有复杂到和编程语言相提并论的时候，就已经腐化到不可维护了。
DSL配置易错：由于我们的DSL逐渐趋于复杂，DSL正确配置与正确解析也变成了一件很难的事情，让我们试想一下一个程序员在编程的时候有各种代码检查的IDE支持都不可避免的Bug百出。而书写一套正确的DSL只会比这更复杂。
DSL难以验证：由于DSL语言的解析已经很难，为此开发一套验证规范更是困难。当我们的系统进行CICD的时候编程语言可以通过AT、UT的验证提高交付质量。而DSL很难做到这一点。
通过以上种种分析表明DRY会引出DSL，而DSL导致系统的可维护性降低。
那么DRY或者DSL就没有用武之地了么？
也并不是，当我们书写一些“基础框架”项目的时候，可以用DSL提供框架的易用性。基础框架面临的问题域都比较固定，所以不会像业务的系统那样需求不断膨胀。所以DSL比较容易长时间维持在一个比较稳定的状态。
