画与软件项目
这篇博客开始写很久了，都已经在我随笔列表的第三页了，然而因为各种原因一直拖着没有写完，所以下面可能出现的最近未必是真的最近。还有最喜欢的两幅画没放进来，有些遗憾，分别是现藏于中国美术馆的万山红遍层林尽染和常熟田。因为一个意外的契机开始，很长时间以来不断的去各种画展，有美术馆、画院，也会去私人的画廊。虽然看不懂，但是毕竟好看的不好看还是能看出来的、赏心悦目，懂不懂什么的......。艺术可以触动人的感性思维，我就属于感性思维有缺陷的，期望能被艺术品感染一下，弥补点这方面的缺陷，或许也能借他山之石在技术方面有所感悟也未可知......吧，总之既然能感受其中的美目前也就足够了，就像某个段子说的，喜欢吃冰淇淋并不需要先学会制冷。看的时间长了就会有一些与自己工作相关的感触。另外，在听一些数学、力学课的时候，偶尔会意外得听到一些关于艺术的认识，我觉得很适合先给大家看一下。
莱布尼茨：音乐，是人类精神通过无意识计算而获得的愉悦享受。
下面这张图是我听北理工力学课的时候，截下来的一张截图：
别的不多说，只说经常在美术馆听到的一类评价，这画画的真像。我个人是觉得画得像应该是相机出现以前的事，之后更多的应该是画家在画中表现出的感悟，或者某些画面对画家的触动，这类甚至在有些摄影艺术中也难以展现出来的令人"愉悦"的"无意识计算"。
画家以画展示所思所感，观者因画中感性被画家心境引导出自己的心境。其实我们做需求的时候多数也是这样的，让客户提需求，很难能提出什么来，但是你做出点东西以后，他就会有这样那样的想法，这样那样的改法，相对这句话我们就是画作者，客户就是观者，我们需要引导出客户的真实需求，是想提高办公效率还是辅助标准化办公流程，我真实遇到过一个项目，客户提出的需求和最终的目的有一定冲突，事实上多数项目都有这种问题，只是有时候不难么明显，不过频繁修改的需求很多都是这种原因。
关于开头的第一句话：“画家以画展示所思所感，观者因画中感性被画家心境引导出自己的心境”。太宗以史为鉴，我现在有机会以画为鉴，品味被画家引导出的自己的心境。以观者的角度体味能被画引导出的对自己的认识，凡事需先认清自己，方能择一适自己所行之路。有了需求就需要开始选型，能从画中发现自己有什么能与之共鸣，我们要使用什么样的技术和框架帮助自己完成项目，选择之前就要首先认清自己，擅长什么、能多大程度上使用从未接触的技术、团队的技术组成、人员性格、配合的默契程度等等。
明确了自身的情况，也更容易设计出自己团队可以完成的业务模型，并在期限内完成它。由于接连不断的去看画，总是有新的想法，所以改了很多次，原本打算在博客最后引出的我对贴在DDD初学指南的对评论的回答，但是由于某天看了王衍成先生的画，于是我决定在这部分写了。关于“业务模型更接近现实”这回事，其实早几年我也是这么想的，但是逐渐改变了看法，业务模型应该是为了更好完成我们的系统而设计的。粗略的看上去似乎并不冲突，但目的不同，结果也会有很大不同。首先，业务模型是抽象的，是为了表达系统最终目的而做出的只为完成系统的目的抽象。相对的”更接近现实“这种说法更贴近于实现。并且现实方方面面就像米特奥拉说的“这个世界的信息是多层次的，无论多无聊的信息都不会用单一的表达形式，存在这样的复杂性”，而好的业务模型一定是以最精简的抽象来表达系统所要完成的目标，比如王先生的这幅画：
其实开始没什么感觉，只觉得是水边倒影，直到走到这个角度：
说句实在话，走到这个角度，其实我也完全不知道他在画什么，但是这时这幅画突然给我一种林间小路的感觉，虽然本来觉得更像是水面，不过感觉到了上午紧张工作的大脑突然放松了，不管作者究竟想表达什么，看画人有所触动也就够了，就像某些阅读理解的答案中常说的：留给读者无限的想象空间。画通过画家对所画之物的抽象来表达画的核心，软件通过业务逻辑的抽象来体现软件的核心价值。
王先生的画几乎画名都是无题，他应该只是想传达他的一种感性，一种体会到的感觉，并不想说明白那是什么，其实感性很多时候是没法说明白的，所以才说是无意识的计算，只要目的达到了，究竟画的是什么不太重要。软件模型也是，最重要的不是设计出了什么，而是是否完成了目标，模型是手段，手段通常是不应该喧宾夺主的。当然，这并不是说手段不重要，画的名字本身就是落在画之外的一种手段：
画名很多时候是核心概念的表达，相对于软件是系统的核心价值，业务方的表达倾向于描述现实他们需要的功能，而这可能并不是软件真正的需求，有时候在需求说明书的不起眼套路段落中，有时候甚至不会出现。他们的目的或许是加快工作效率，或许是限制职能权限，或许是调整业务方向，如果不确认好真正的目的，只按他们对现实的描述去做，绝大多数时候会导致后期大幅调整，这一点不只是业务，在技术理论中也是一样的，某一处差之毫厘，整个系统谬以千里。
这画说实在初看时没什么感觉，然而一看名字，乾坤一草堂，再看画面，以草堂为中心顿感草堂之简与画面自然映照，其草堂当为诗人画家观湖光山色之处，满幅乾坤图尽收与草堂之中，顿感豪气，令人精神振奋。名字之重要程度可见一斑。而做需求的时候也不能仅仅关注系统之内的功能，系统之外的主题更是核心。
王先生的画对我们来说可能有些太抽象了，我们来看一个不那么抽象的，并且有名字的：
这幅画也是在中国美术馆看到的，时间由点长了，没记错的话画名叫蓝天，作者是张立国先生。这幅画最重要的部分很显然左上角的一小块蓝天，能说明它是蓝天模型的也只有一小块云，或者还有它的位置，然而已经足够表现出它作为核心子领域的业务概念了；这幅画的架构清晰，表达出来的业务对象也非常明确，但并没有去逐渐贴近现实去建模；三面围墙（姑且认为是墙吧）和墙下之人以及一点蓝天就是整幅画，画中之人或许在望天或许是渴望轻松自然；墙的颜色不同，也或许是现代化的生活筑起的高墙隔开了人与人之间的关系，然而他们或许都是向往着同一片蓝天，当然三人也可能在同一件屋子中。至于究竟如何，或许不重要，每个人的触动或许也是如人饮水冷暖自知，看懂画家在画什么并不重要，只要对画有所触动，便也算没有白看，画的价值也在与此。清晰的架构和业务模型，更利于表达相对清晰的感情，至少我的感想被限定在了一个小范围内，而王先生那副画，有时看着像林间小路，有时候又觉得草树池塘，偶尔还会春绿秋黄，但一切都是为了最终目的，无题亦是主题，不能因为技术洁癖或对模型本身的最求而使目标有所偏差。一幅画要想感染人，我想画家并不是单纯的只想画得像，不然照照片就可以了；软件同样如此，我们开发软件目的并不是要让它做出现实人做的事，而是让用户借助它更好的完成工作。
刚刚提到了，好的模型一定是最简化的模型，大家都明白这个道理，但是做的时候，经常会不自觉的为了让模型看起来逻辑上更完整，更“合理”而增加些东西，例如群里曾经讨论过论坛帖子的回复是否要作为帖子聚合的对象，因为帖子删了，回复的存在可能就没有意义了，但是这个看起来逻辑上更完整的约束是否有价值就未必了。1+1=2，是因为抽象出了现实中的数量这一属性，但是如果一个1是男人，另外一个是女性，这1+1极有可能结果会是3，然而数学可不能这么算，所以业务模型的抽象与真实的现实，并不一定要统一。
这是在一家私人画廊看的，虽然不是画，不过也差不多，关于这件作品的讲解：http://www.vart.cc/guides/1141?fragment=9799，我也不多介绍了。此作品的作者农西奥的一句名言，大家有没有觉得比较熟悉。。。
到这可以先小结一下开篇的那个问题了，模型未必应该贴近现实，而是抽象出现实的某一部分，其实这也并不是很贴切，模型的目的是为了更好的实现整个系统，只是一般情况下这样更容易开发而已，关于部分抽象这事可以看一下下面的作品与现实的对比，我就不多说了，更何况一个完全不按现实去抽象的模型就一定不利于系统开发么，面向对象出现以前就没有好的软件系统么？
上图为潘天寿先生的画与原型对比。其实前些天公司组织去长城拓展，我拍的照片总觉得不好看，一度非常怀疑我莱卡的镜头，后来想明白了：之所以看着很好看，但拍出来效果不好是因为人会选择性忽略一些不重要的东西，相机不会，所以有电线等东西照进来，所以会感觉没看到的好看，经常在美术馆拍的画也是，现场看很漂亮，但是很多画是在玻璃保护中，玻璃的反光导致照下来的根本看不出效果。所以画也好我们的模型也好，如果想要满意，该忽略的东西无论在现实中多重要都是要忽略的。
这个问题我的看法大概就是这样了，似乎这个结并不怎么小，不过就不要在意这些细节了。
开篇就是一张抽象画可能不是很容易找到方向欣赏画。其实小学就学过，万物都是有联系的。画和程序都是人创作出来的，既然不懂美术，可以试着从软件的角度来欣赏一副画，即使和原作者想表达的不同，只要能有所得就不算白看了，就像nginx，本来是个静态服务器，但是有几个人真是从静态服务器的角度用的。
最容易看明白的画当属素描了（其他如静物画和油画也多包涵浓重的感情色彩），我之所以觉得素描的传达的感情色彩少，主要是因为它多是一种记录写实，是真正作品创作前的一个标记，用来引导艺术家回忆起当时的感觉（不算学生练笔的），毕竟直接在荒山野岭画出成品来即使有素描版，多半也不会展出，我反正是没见过。也不是说素描一点感情色彩都没有，当然是有一定倾向的，但是我看不出来（极个别除外），手里画的图片太多了，常见的铅笔素描没翻到，但是找到了几张水墨写生：
素描很多时候看不出，我个人觉得可能也不需要看出画家想表达什么，多是对应成品来欣赏的，虽然这两幅也不是完全没有韵味。在软件中，这类还比较多，比如一些通用的开源框架，如Spring Boot，它没有业务含义，但作为一个可以拿过来就用组件也是非常不错的，本身也是相当不错的架构。
基础设施在有一定的业务倾向，甚至于需求讨论之前就可以进行，但可能是伴随着业务的开发才逐步完成的。关于业务模型的建立和落实到开发上，多数现在还是一个并列的过程，一次性设计一个完整的模型，之后再按着模型按部就班的开发。但是这种方式其实是几十年前的经典，在一定规模下，还是成功的。而现在已经不再是那个时代了，市场瞬息万变，政策也总在调整，需求无法一成不变。若是一个工期一年以上的项目，按第一版出的模型去做，股市可能都差了几千点了。其实，画画也是需要一遍一遍迭代的。
先有一个大体方向，然后从主要部分开始，一点一点的丰满，再细化迭代。我试验过一些建模和落地的理论，其中在项目中最成功的应该属于测试驱动+T型功能导向集成（在功能构建中描述过）。比如人像，脸当然是最重要的部分，于是先构造出头部轮廓，再以头部轮廓为基础，逐渐延展开来。对于开发，我们就先开发最核心、稳定的模型和功能，以此为基础，逐渐开展相关的模型和功能，并根据实际情况逐渐调整，比如今天碳...不够...黑，就多图两笔...什么的。测试驱动开发也是一个非常好的实践，很适合辅助功能导向的集成。以单元测试组成业务的结构，也就是画的轮廓组成，最初的被测试方法内部可能只是返回了个伪造的结果，过程中也不一定时时刻刻都是完善的，脸第一次上色的第四幅看上去并不怎么好看，集成测试开始后，结合整个画面也可以看出到了第五幅脸似乎颜色有些过重了，就根据当时的具体情况对功能做一定的调整，为了项目的顺利完成，对需求和功能甚至于模型进行适当的删减调整也是必要的。当集成测试完成，色彩填充画的各部分的精神被联结起来，被单元测试过的代码内部实现丰满连通，画就完成了。
其实，我本来是想用齐白石老先生的草稿来着，那一系列草稿更明显更丰富，然而我没找到，那些草稿在画院，偶尔会展出，碰到的时候再说吧。对于上面这画，人像应该就属于核心子域，但是只有一个核心是不成的，其实经常也能看到一些不错的话，但是画面不够丰满，给人的感觉总想缺了什么的。 对这幅画来说，画面上的题字恰到好处。软件架构通常也是围绕着业务核心，延展出各个通用子领域，各部分相互独立，但并不能缺少。一旦某部分的业务膨胀，也可以将其独立为一个上下文，它对于原有系统是一个支持子域，对于自身也是一个核心子域。也有遇到过这种情况，一幅画上的题字特别漂亮，大家都不去关心主要部分的画，而是看字了，而既然被展出了，就说明了其艺术价值。这种情况也并不是坏事，比如互联网企业本身就是随着市场发展而变化，比如只去京东和亚马逊自营买东西，大家也少不了用支付宝。
核心子域和非核心子域在开发中投入的比重也未必一定是核心最重，比如上面的乾坤一草堂。我们在做项目的时候，每一层面都是在找一个平衡，因为平衡并不是有固定规律的，所以很多书才会说，软件是门艺术。我在网上听清华大学数学建模课程的时候，姜启源教授曾讲过，技术大致有章可循，而艺术无法归纳成普遍使用的准则。虽然姜教授是在讲数学建模，但我认为贯穿整个项目的每一个部分都是这样的，无论是需求与开发团队资源之间的平衡、模型距离现实远近之间的平衡，还是开发时实现的优雅与性能之间的平衡（当然，个别时候未必不可兼得）。这些平衡并无一定之规。比如下面这幅环保题材的画，小姑娘、彩色的气球、小狗、后面的烟囱、以及看不清后面是工厂还是废墟的影影绰绰，无处不是模糊与清晰之间平衡的体现，清晰一点或再模糊一些都未必能有如此效果。
也不必为框框架架约束，不一定实现的要华丽。极有可能很简单的实现也能恰到好处，当然，恰到好处说起来容易，既然无法规定普适的规则怎么办呢，我的经验是，当模型或实现等可以让自己觉得不别扭、或者念头通畅就可以了。开头莱布尼茨的名言暗示了一点，我们的无意识计算或者直觉可以帮助我们找到自己根据现有资源所能达到的最好平衡。
最后再看一幅画，这幅画非常简单，但传达的感性非常丰满。我们做软件也是一样，只要有合适的数据结构，体会画的动与静，抽象程度未必需要非常精细，特地强调这点因为说起来容易，其实很多人，尤其是有代码洁癖的人非常容易把数据结构设计的非常精致，下手之前还在想要把握分寸，但是一旦开始就一发不可收拾，我以前就经常这样。下面这幅画中核心部分是一个出门迎接阳光的人，这人看起来只是随便画了些轮廓阴影，但是恰到好处，线条并不觉得乱，而大面积的房间简约而不简单，墙上一幅树叶既使画面丰满，也能突出主人向往春天，我初看时还有一种在家临渊慕鱼不如出门享受阳关，退而结网脚踏实地一步一步走出去的感觉。
------------------------------------------------------------------------------------------------------
公众号：
