戏说领域驱动设计（三）——困境

　　我第一次捧起老艾那本《领域驱动设计》，惊为天人。吾辈上下求索数年，这不正是终极之大道吗？结果只三天热乎劲儿，“什么玩意儿”是对这本书的最好评价。好好的一本书让我“弃之如敝履”，差点就“小舟从此逝,江海寄余生”了。几年过后读了网上一些老baby写的吐槽DDD的文章，几乎视其为知音啊，那概括的真是精辟，绝对是个性情爽快的真汉子。借他的花我也献献佛，也说说DDD这点事儿，好好的一门儿学问怎么现在变得神乎其神上升到哲学、玄学的地步，不得不感慨“江山代有才人出”。

 

 　　上面的图展示了使用DDD的六个困境，相信每一个学习者都会遇到其中的一个两个或多个。

 　　第一层：“本末倒置”，技术人员喜欢将精力放在战术部分而忽略了战略，喜欢讨论各类设计模式、框架，部分个体系统设计的相当不错，整个系统确是千疮百孔。这种抓不住重点的情况，造成你虽然使用了DDD，确看不到成效。再加上ODD这种设计方式做起来也挺复杂，上下怨气冲天。最终给你的结论就是“DDD不行”。此外，过度关注技术使得你的系统的好坏完全依赖于程序员的个人素质，问题是好的程序员全干管理去了。上有屁股下有脸，他也没时间从细节上把握系统建设。DDD的带头大哥“Vaughn Vernon”在其名著“实现领域驱动”一书中开端便写“战略”，那就是告诉您这是需要第一时间关注的部分。您在读书的同时也得猜测作者为什么这样安排章节，为什么与老艾那本开山之作组织方式不同，这得细心品味一下才行。

　　第二层：“门槛高”，即便是DDD的战术部分，对于研发人员也有较高的要求，如：数据库设计、代码规范、全局系统理解度、设计模式、系统优化策略……。过去您搞面向过程，要考虑数据库的优化；现在您搞DDD除了数据库那点活儿，您还得考虑模型的设计，比如有哪些模型？它们间的关系是什么？，里外里实现难度增加了一倍以上。再者，DDD还鼓吹头脑风暴（其实就是开会）呢？您作为一个高级工程师或者团队扛把子，不得参加参加？而实际情况，一天已经800个会了，谁还有时间、有精力去做模型设计。好不容易有个喝口水儿的时间，想来还有一个千字周报没写。

　　第三层：“晦涩”，网上DDD相关文章中很喜欢使用晦涩语言。大部分文章作者的分享精神值得赞扬，可就是有些大师喜欢搞玄学，本来一个事情可以用简单的语言表达出来，咱必须得上升到哲学层次。写文章的目的不是“传道、授业和解惑”， 是为了欣赏你们一副无知的样子。DDD里就那点东西，说白了就是建设前先把大系统拆分一下，再对小系统按其情况选择一个编程模型，再稍微注意一点服务间的交互，这事儿就齐了。那些专家级文章再多写一点就开始指点人生了，这臣妾消化不了啊。

　　第四层：“无案例参考”。比如微服务，你可以找到大量的落地方案，对于DDD有价值的参考非常少，大部分的案例都脱离了实际的业务，离开领域谈设计也不能说没意义，现实中您计划使用DDD的业务场景可能非常复杂，一个小细节都可能阻碍工作的进展。所以只有实际参与过DDD项目才能了解系统从分解到建模再到落地的一系列流程中所应注意的东西。片面的案例对于有经验的工程师可以说明问题，对于小白则造成了不小的困扰，从内心深处排斥学习。可话说回了，也不太可能把自己公司的项目全摆出来让您看，这涉及到法律及安全的责任。这种情况基本无解，比较好的方式是找个不重要的模块背着领导自己搞一把，万一成了呢？

　　第五层：“过度吹嘘”，部分文章和书籍作者过分的夸大某些战术架构的优势而忽略了其缺点，甚至对于DDD本身也做了夸大，造成开发与运维成本的成倍增长及至于系统无法快速扩容甚于不得不重写，比如CQRS、ES就特别容易被滥用。此话羞于开口，我知道ES的编程模型可从来都没在实际系统中搞过，一是有代替方案二是害怕（代码都是写给自己的，出了问题您也得自己维护，除非您打算写完就直接跑路）。在座的您各位也包括我自己应该是很喜欢技术的，面对花花世界中那些亮眼的、高大上各类技术和名词，很容易被其诱惑。到不是说多学点技术不好，而是要学会如何控制自己去选择最为合适的技术方案，这是您对公司的责任。请对技术保持敬畏之心，那东西是双刃剑可以成全你也可以逼你挥刀自宫。

　　第六层：“营销绑架”，软件行业喜欢把简单的东西搞复杂，主要的目的就是让人觉得很高大上，越晦涩越好。让人听上去感觉很牛掰，但是听不懂。如中台、低代码、DDD。这样的系统具备极高的营销价值，但落地非常困难，尤其是在资源方面无法与理论对齐的时候。销售拉项目时通常会竖立各种Flag，可只要项目一到手就由不得客户了。至此，DDD就沦落为一个拉项目的口号，可怜那！

　　面对上面的六种困难，的确是没什么好的解决方案，即使说出来也不过是纸上谈兵。家家过日子，家家有本难念的经。“尽人事，知天命”：前一句告诉您需要加强自身的修养，需要时时报有一种客观、务实乃至对于技术敬畏的态度；后一句告诉您世上很多事情本身就是无解的，您上面有领导，领导上面还有领导。那就学会聪明一点换个思路解决问题。咱都是搞技术的，技术是朴素的，千万别天天夸夸其谈。您个人是爽了，但活总得有人干，让下属天天后面骂着您也不好不是吗 ？

　　另外，假如您在组织内有一定的权力，DDD可以帮你打通任督二脉，至少在战略上还是可以有效的指导系统建设的。假如您空有一身抱负却摊上了一个不懂还要装懂的领导，那就熬他，看看谁最终笑在最后。最后一点，请把战术设计部分的责任放在您的团队最靠谱的那个人（技术好还听话）身上或干脆自己来，尤其是涉及需要使用ODD的业务时，千万别天真的组织一堆人坐在一起聊设计。人一多就众口难调，七嘴八舌的一会儿就把您带歪了，还头脑风暴？整个就一喷空沙龙。家有千口主是一人，如果你敢拉会那就需要保证这里有一个人敢拍板儿做决定。最后，请务必不要忽略人性中的自私，同水平技术人员讨论的时候最终往往就对人不对事儿了，容易让团队产生矛盾，万事以合为贵嘛。

　　如果您下面有几个比较有能力的大哥，放到不同的业务中。服务拆分（拆分阶段尽量让骨干参加，后续这帮大哥还得负责各子系统建设呢，不过得有个主事儿人能拍板儿）的好，实施阶段好一点差一点也太不影响什么（严肃来讲：是因为好的拆分能够明确子系统间的边界，这种天然的隔离机制会消除部分不良设计所带来的影响），用户又不知道，反正只要功能对就行。好的系统也不是设计出来，是迭代出来的。再说了，有生之年我估计也没机会参与火箭、航天飞机的软件设计了（这类系统不允许BUG的存在，需要采用非常严谨的软件开发流程进行管控），让我们拥抱迭代吧！！！

　　本节谈了DDD的困境，也说了一点团队管理的事儿。公司不同，文化不同，按需采用合适的、适应您团队的管理办法和系统实施技术方案。另外，心急的爷们不要着急想看代码，先修炼内功，高手都需要内外兼修的。下次咱们聊聊DDD都说了点什么东西，怎么也得有个大概的感性认识吧。您就算再不愿意看到那些晦涩难懂的词我也得说（主要是不说我也不知道用什么词代替，我也在是在DDD的路上挣扎呢，回头没岸了），万一和同行聊的时候您满嘴大白话，不专业。