先有一个大体方向，然后从主要部分开始，一点一点的丰满，再细化迭代。我试验过一些建模和落地的理论，其中在项目中最成功的应该属于测试驱动+T型功能导向集成（在功能构建中描述过）。比如人像，脸当然是最重要的部分，于是先构造出头部轮廓，再以头部轮廓为基础，逐渐延展开来。对于开发，我们就先开发最核心、稳定的模型和功能，以此为基础，逐渐开展相关的模型和功能，并根据实际情况逐渐调整，比如今天碳...不够...黑，就多图两笔...什么的。测试驱动开发也是一个非常好的实践，很适合辅助功能导向的集成。以单元测试组成业务的结构，也就是画的轮廓组成，最初的被测试方法内部可能只是返回了个伪造的结果，过程中也不一定时时刻刻都是完善的，脸第一次上色的第四幅看上去并不怎么好看，集成测试开始后，结合整个画面也可以看出到了第五幅脸似乎颜色有些过重了，就根据当时的具体情况对功能做一定的调整，为了项目的顺利完成，对需求和功能甚至于模型进行适当的删减调整也是必要的。当集成测试完成，色彩填充画的各部分的精神被联结起来，被单元测试过的代码内部实现丰满连通，画就完成了。
其实，我本来是想用齐白石老先生的草稿来着，那一系列草稿更明显更丰富，然而我没找到，那些草稿在画院，偶尔会展出，碰到的时候再说吧。对于上面这画，人像应该就属于核心子域，但是只有一个核心是不成的，其实经常也能看到一些不错的话，但是画面不够丰满，给人的感觉总想缺了什么的。 对这幅画来说，画面上的题字恰到好处。软件架构通常也是围绕着业务核心，延展出各个通用子领域，各部分相互独立，但并不能缺少。一旦某部分的业务膨胀，也可以将其独立为一个上下文，它对于原有系统是一个支持子域，对于自身也是一个核心子域。也有遇到过这种情况，一幅画上的题字特别漂亮，大家都不去关心主要部分的画，而是看字了，而既然被展出了，就说明了其艺术价值。这种情况也并不是坏事，比如互联网企业本身就是随着市场发展而变化，比如只去京东和亚马逊自营买东西，大家也少不了用支付宝。
核心子域和非核心子域在开发中投入的比重也未必一定是核心最重，比如上面的乾坤一草堂。我们在做项目的时候，每一层面都是在找一个平衡，因为平衡并不是有固定规律的，所以很多书才会说，软件是门艺术。我在网上听清华大学数学建模课程的时候，姜启源教授曾讲过，技术大致有章可循，而艺术无法归纳成普遍使用的准则。虽然姜教授是在讲数学建模，但我认为贯穿整个项目的每一个部分都是这样的，无论是需求与开发团队资源之间的平衡、模型距离现实远近之间的平衡，还是开发时实现的优雅与性能之间的平衡（当然，个别时候未必不可兼得）。这些平衡并无一定之规。比如下面这幅环保题材的画，小姑娘、彩色的气球、小狗、后面的烟囱、以及看不清后面是工厂还是废墟的影影绰绰，无处不是模糊与清晰之间平衡的体现，清晰一点或再模糊一些都未必能有如此效果。
也不必为框框架架约束，不一定实现的要华丽。极有可能很简单的实现也能恰到好处，当然，恰到好处说起来容易，既然无法规定普适的规则怎么办呢，我的经验是，当模型或实现等可以让自己觉得不别扭、或者念头通畅就可以了。开头莱布尼茨的名言暗示了一点，我们的无意识计算或者直觉可以帮助我们找到自己根据现有资源所能达到的最好平衡。