Eric Evans：为了项目能够随着开发工作的进行加速前进，而不会由于它自己的老化停滞不前，设计必须要让人们乐于使用，而且易于修改。
要做到Eric Evans说的柔性设计是很难的，但是并不是做不到。
试想一下，我们平时在开发的时候是不是一直都在使用一些不需要关注底层的框架/组件，如果需要一些简单扩展的时候也能很方便地做到（如Spring、同事开发的操作日志组件、通知组件）？
那有人能做到，就有经验可循。
工作这段时间我也一直在观察那些能写通用可扩展组件的同事，发现他们都有一个特点：基于现状，超越现状。
基于现状： 梳理现有业务，圈定确定的范围，提出解决方案A。
超越现状： 基于方案A考虑当前组件/业务未来将要遇到的问题，并抽象化不同的场景，而当前版本只实现A对应的场景。
以下是我对，如何做到这点的基本看法。
无论是基于现状（现在的业务场景）、超越现状，必须得先了解现状是什么。
对于怎么了解现状，我的观点是：
我们必须和产品经理/领域专家详细了解业务全貌。这里有人可能就会说，我只是做这个系统的一部分而已，没必要全盘了解吧？不是这样。你如果对业务全貌有了了解，那你自己就可以划分模块范围，能够掌控自己模块的输入和输出，也可以知道自己模块从初版到终版会遇到哪些需求以及相应的挑战。
我们尽力和产品经理/领域专家详细了解业务实现细节。这里有人可能又会说，怎么才算尽力？需求文档上的东西我都了解了够吗？这是一个很复杂的问题，有很多方法论，不同经验的人有不同的方式，所以尽自己当前的能力去了解就好。
做到从全局出发了解局部细节即是了解现状。
在了解现状（理解业务需求）后，我们可以设计并提出方案A，优化方案A提出基于现状的可扩展方案B。
A&Q
做到这一点就能做到柔性设计吗？
这依赖于实现人员的能力，如果想得全面，考虑到的现状是整个系统生命周期，那就是一个非常优秀的设计，对于在系统生命周期中途接手维护的你来说，这个设计就是柔性的。
