《领域驱动设计》阅读笔记 第1章 消化知识

ddd小白，一篇章节便能激起了心中涟漪，感慨之初，记于笔下。

 

 

第1章  消化知识

 

用醍醐灌顶、茅塞顿开来形容此章短短的文字，实不为过。

简单介绍背景：旅游互联网，B2B，初创公司。产品设计-代码开发的衔接有过两种明显形式：

1. 项目的推进由产品部起头，收集、分析、过滤需求，形成原型文档（word，excel，visio，axure），提交CTO、CEO评审（整个产品90%的原型、流程、字段），交付开发、测试工程师。

开发工程师花一两天理解、讨论原型文档，而后建立数据库表，开撸代码，按模块交付测试工程师。

2. 曾经有一段时日，管理层要求打破部门的界限，以项目组为单位，每个项目组有产品经理、开发工程师、测试工程师。项目小分队高内聚，分队间低耦合。开发与测试充分介入产品设计阶段，产品原型文档定稿之时，开发与测试心中也将早已心领神会。

经多方因素，情景2还是回到了情景1的状态，主因有：部门座位区分离、部门内部讨论频率更高、项目较多开发节奏甚紧导致开发没有更多的时间加入产品设计（一句玩笑也害人——作为开发的你和产品讨论一天设计，他的产品设计有了，你的代码还没有——啊，多么痛而现实的打工者）。

回想上述1、2情景，孰优孰劣，或更优何在？

我曾与公司一位善于思考的产品经理讨论时提出观点：若产品的设计已完成了较小粒度（也许是按模块，或按功能）的闭环，便可提前交付开发——在该产品所有功能模块都设计完之前。意在平衡"完全设计再交付开发的瀑布"与"完全重叠讨论产品的时间浪费"之间的关系，找到平衡点。现在想来，当时的愚见仍然幼稚。

 

一直萦绕耳边的有两个思考：

1. 曾听到有经验的开发人员向产品经理抱怨：你们的产品设计要有模型建立，经过实践，不要我们开发做着做着发现模型不对又调整。（模型是什么？word、excel、axure？）

2. 几个月前，我负责开发一个企业基础设置管理的模块，市面上我能普通查找到的做法都不符合CTO对我的要求，故我只能重新做代码设计（产品经理忙别的项目去了，此管理模块直接由CTO表达期望结果，由码农我直接实现）。在经过了长达一周的反复检验、讨论、再检验，终于定下了较为详细的代码设计（即类之间的关系、界面交互效果、持久化关系）。其中需要另一位善于技术框架的开发工程师提供相关接口，在简单-详细-详尽描述意图后，他拒绝了接口的提供，原因是：这样设计是不合理的，市面上没有这样的设计，没人这么做。而我也确实没有十足的理由进行反驳，只能退到"用户习惯、设计要求"的挡箭牌之后（市面上没这么做的，就说明咱不应该这么做吗？）

阅读了第1章 消化知识，我有了第一份答案（也许未来的第二份会完全推倒，那就太棒了，说明我在进步）：

答1：应该建模，尤其对于复杂业务逻辑，以减少（肯定无法避免）需求变动带来的较大调整，但是建模不只是产品的事、更是开发的事，建模的结果可以是若干实现核心业务逻辑的单元测试程序。

答案受启发于书中P9：随后，我们又拿出一部分工作时间进行了几轮这样的讨论，我觉得自己已经理解了足够多的知识，可以试着编写一些代码了。我写了一个非常简单的原型，并用一个自动测试框架测试它。我避开了所有基础设施。这个原型没有持久化机制，也没有用户界面（UI）。这样我就可以专注于代码的行为……虽然它使用的是虚拟数据，而且像控制台输出的是原始文本，但确实是……执行实际的计算。

对于复杂建模，开发可以对核心业务逻辑进行梳理后，建立无关界面、存储的类间交互，形成单元测试，并提交产品设计优化核心代码——这是不是比原型文档更接近与模型的感觉了？

答2：最终的结果，善于学习的开发工程师一边保留着他的坚持，一边给了接口，毕竟要争论就不得不多次面对再设计与撕X的过程。市面上的没有，并不代表我们的开创就是错误的，这不是盲目创新，而是要忠于用户需求（当然至于这是否是用户需求，我认为开发人员应充分相信团队的产品设计者，毕竟这是合作的前提）。

答案受启发于书中P3：软件的核心是其为用户解决领域相关的问题的能力。所有其他特性，不管多么重要，都要服务于这个基本目的……大部分有才能的开发人员对学习与他们的工作领域有关的知识不感兴趣，更不会下力气去扩展自己的领域建模技巧。技术人员喜欢那些能够提高其技能的可量化问题……技术人才更愿意从事精细的框架工作，试图用技术来解决领域问题。他们把学习领域知识和领域建模的工作留给别人去做。软件核心的复杂性需要我们直接去面对和解决，如果不这样做，则可能导致工作重点的偏离。

"很少有开发会来探讨和深入了解需求"，被我固执地认为是那位善于思考的产品经理做出的好的评价 :)

 

书中P11：领域模型的不断精化迫使开发人员学习重要的业务原理，而不是机械地进行功能开发……模型在不断改进的同时，也成为组织项目信息流的工具。模型聚焦于需求分析。它与编程和设计紧密交互……模型永远都不会是完美的……模型对理解领域必须是切实可用……以便使应用程序易于实现和理解。

这进一步向我们传递：建模应该有开发的身影，且应该是项目组共同商讨、一同反复检验和完善的产物，是知识积累的方式，是未来程序实现的原型，是关键代码的主心骨。

 

一年前我接触了公司产品中第一版订单系统，流程错综复杂，特殊性较强，在深刻了解需求后——复杂之处在于：对于订单流程中的不同状态，买卖双方可操作的内容不同。若仍使用代码中的if-else解决，代码量之多、代码意图之隐晦将是一枚定时炸弹。在参见23中经典设计模式之后，决定借鉴状态模式——重写订单后端核心业务逻辑（前端不变）。能看到的效果是：原if-else的设计，bug总是改不完，总会有逻辑错综交互而疏漏之处；状态模式的设计，将订单状态间解耦，独立变化，独立发展，能找到业务逻辑bug，那是你本事。

一年后的今天，产品升级换代，第二版订单系统对第一版做了调整，增加了买卖双方分开处理、不同来源走不同的订单流程的复杂性，在参照（照搬绝壁也是个死）自己去年的状态模式设计后，加入了桥接模式，更独立处理"订单操作"与"订单状态"。逐渐体会到了书中P12的航程-货物示例——我们将超定规则转移到领域对象中——订单交互逻辑与界面、持久化无关，完全是判断走向与限制可修改属性等内存级的事情，故将逻辑抽离service，放入domain，不但利于代码寓意传递，也利于无关ui、db的单元测试，更利于领域业务独立处理。但我遇到了一个问题：类似超定规则的事情还有很多，如何把他们都扔到领域对象当中，是一个问题，最后我疲于稳定，妥协于项目进度，暂且延缓。此时我看到书中P14的一句话似乎提点了我——我并不建议将这些精细设计应用到领域的每个细节中。第15章将深入阐述如何关注重点以及如何隔离其他问题或使这些问题最小化——天啊，我已经迫不及待跳到15章寻求答案了，但我还是原意保留这个疑问，因为的确当下我只需要知道我似乎歪打正着做了一件对的事情就好了，至于理由，我可以下一步再知其所以然。

 

2016年写代码多，读书籍少，博客园也来得少了。阅读笔记有一些好处：

1. 阅读本来只需1h，可记录却在要求你反复细品值得细品之处。

2. 阅读的过程中不免思考，放下书本，思考一会，记录下来，利于思路的整理与表达，甚至可能发现更多闪光点。

3. 一边阅读，一边记录。当你阅读完一整本再回头看这些阅读笔记，一定会发现自己以前是个傻x，太棒了，成长也。

 

文初提到"醍醐灌顶、茅塞顿开"，意在：有一些缠绕心中的问题（这些问题可以不予解决的确也能碌碌终生，毕竟不是代码问题那样务必需要解决的硬骨头），但当你遇到一些观点尤其是已经过实践认证的大神的观点，能够指引甚至直接给出问题的答案时，简直直戳心窝——在你最需要时出现的，带来的幸福指数最高。

愿读者朋友们都能"遇"到如此"暖心"的读物。