论精益与领域设计

原创
感悟
DDD, 感悟

开始之前

你是否遇到过这种事？一个“好”工程师，非常喜欢学习和钻研新的技术知识，JEE时代学习Spring，SSH时代学习分布式，大数据时代又开始学习Hadoop,Storm,云时代开始搞docker,k8……然后成长为一名“架构师”了，在他的公司，有一个重要项目，于是乎他决意把这个项目设计成一个全分布式的系统，毕竟“时髦”嘛。每一个小的开发团队负责分布式中的一个服务。由于架构师对这些程序员缺乏必要的指导和控制，每个程序员只熟悉自己负责的一小块工作，彼此间缺乏沟通和协作，这个项目的概念完整性很快就被破坏了，他们开始自行其事，分布式服务间大量的远程调用导致了性能和可伸缩性等多方面的问题，开发、测试、运维的工作难度与日递增。慢慢的，项目的开发人员，离职的越来越多，包含最初的架构师，代码的维护越来越难，最终只能重构，将十几个分布式服务合并为三个相对独立的集中应用。最初良好的架构，到最后沦为废墟。中间一位离职的程序员，换了一家公司，涨了一点工资，开始了另一段新系统建设的“狂欢”，周而复始，随着年龄的增大，他不再能够从软件开发中享受到乐趣，开发的生涯，对他来说痛苦开始多余快乐。学习新技术，他也比不上年轻人。运气好的话，他可以转产品、管理或做业务，运气不好的话，还得继续码代码，毕竟要养家糊口。从一家公司换到另一家公司……

“如果”

这是一个悲剧的故事，尤其是最后那位程序员。然而这可能是国内很多软件开发人员的真实写照。那么，我们从“上帝视角”来开看待这一切，会怎么样呢？先从“如果”开始吧。

  • 如果最初那位“架构师”不盲目赶时髦，压制住自己想通过该项目展示自己功力的想法，转而根据实际的业务需要和人力资源情况，考虑适当扩展性、可维护性后，再设计这套架构，会不会好点？
  • 如果那位“架构师”抽出时间，找到合适的方法来指导和控制开发的程序员，保证整个系统的概念完整性，架构会不会发挥出它应有的能力和好处呢？
  • 如果那位程序员，发现自己志不在编码，早日转行找到适合自己的岗位，生活会不会幸福很多呢？比如之前中关村离职开水果店的那位成功”程序员”（一日程序员，终生程序员）
  • 如果那位程序员，能够及时意识到学习新知识的重要性，并以此为乐，或许，他会成为另一位最初的那位架构师
  • 如果那位程序员和那位架构师，在开始一切之前，与领域专家进行详细的领域建模，能把握相关领域的核心知识，对他们的进一步前行，转行、进阶架构、进阶CTO，会不会带来额外的好处或便利？

结论

当然，世界上不允许有如果，也没有后悔药。废话不多说，如果要在技术上继续走下去，总结起来无外乎几点：

  1. 追求精益，即提高效率，避免浪费，哪怕你当了CTO、CEO；
  2. 重视沟通，重视团队管理，而不仅仅把注意力集中在新技术和良好的架构上；
  3. 一切都要透过现象看本质，把握核心要素；
  4. 保持危机感和饥渴；

如果不想在技术上走下去，可以到这里就结束了。友情提醒：当管理可比做技术难太多了，人心比海深。

我们从现在回头看软件开发的历史，开发模式的演进，从瀑布式到极限到敏捷，到现在的DevOps，还是技术的演进，其实都是在1、2两点上进行不断的尝试和优化。最终，1、2其实都可以归于精益的思想。对于精益，我就不多叙述了，强烈推荐精益创业这本经典，虽然书本身是写给产品和创业者的，但精益的思想是普适的。
而3、4两点是针对个人的，对应到软件开发，就是DDD的出现。DDD最大的作用就是为了达到第三点（当然，对第2点也好很好的体现），把业务上真正核心要解决的问题进行建模。
这里我就不再详细阐述DDD的具体内容了，随便一搜一大把，下一篇我会就其中几个比较重要的概念进行解释，但是千万不要把DDD与单纯的以名词建模混为一谈，我曾经见过直接把一个业务中所有的名词抽象出来进行OOP的……囧
推荐看InfoQ几年前出的Domain-Driven Design Quickly(dddquickly)或中文精简版 ，有一定基础后，再去看原作者，也就是DDD概念的创始人Eric Evans的大作 Domain-Driven Design: Tacking Complexity in the Heart of Software

细思极恐，软件开发最终也还是跟哲学扯上了。

本文由 EdisonXu - 徐焱飞 创作，采用 CC BY 4.0 CN协议 进行许可。 可自由转载、引用，但需署名作者且注明文章出处。
本文链接为http://edisonxu.com/2017/03/17/lean-and-ddd.html
如果您觉得文章不错,可以请我喝一杯咖啡！
赏
DDD, 感悟