人们经常谈论优秀设计和糟糕设计。你的设计属于哪一种？

有很多软件开发团队的设计从来经不起思考。他们采用一种我称之为“任务板挪卡” 的方法来代替设计。团队有一个开发任务清单，比如 Scrum 产品待办列表，其中的任务被张贴在“任务板”上，然后他们可以将一张便利贴从“任务板”上的“待办”泳道移动到“进行中”泳道，这就是“任务板挪卡”。

产品经理提出待办项（任务），然后来一次“任务板挪卡”，这便构成了关于设计的全部“真知灼见”，剩下的就交给程序员大神们去疯狂输出代码。很少有团队会这样做，如果真的这样做了，业务就会为这些不存在的设计付出最高昂的代价。

这种情况常常是因为团队必须按照苛刻得近乎残忍的时间表去发布软件，管理层只会使用 Scrum 控制交付节奏，却对它最重要的信条之一： 知识获取 （Knowledge Acquisition） ，视而不见。

在我独立进行咨询和培训的经历中，经常会遇到相同的情境。软件项目如履薄冰，所有团队成员都在努力地维护着系统稳定，每天面对着代码和数据打补丁。以下是我发现的一些潜在问题，有趣的是，DDD可以帮助团队轻而易举地避免其中的一部分问题。我先从高层次的业务问题开始，然后再讨论技术相关的问题：

• 软件开发被视为成本中心而非利润中心。这通常是因为从业务的视角来看计算机和软件技术是必要的消耗而不是战略优势的重要来源（不幸的是，在根深蒂固的商业文化下，这种观念不太可能被转变）。
  
• 开发人员热衷于技术并通过技术手段解决问题，而不是深入思考和设计，这会导致他们孜孜不倦地追逐技术上的新潮流。
  
• 过于重视数据库，大多数解决方案的讨论都是围绕数据库和数据模型，而不是业务流程和运作方式。
  
• 对于根据业务目标命名的对象和操作，开发人员没有给予应有的重视，这导致他们交付的软件和业务所拥有的心智模型之间产生巨大的分歧。
  
• 上面的问题一般是业务协作不顺畅而导致的。业务干系人常常浪费大把时间闭门造车以实现各种无人问津的需求，或者只有一小部分能被开发人员采用。
  
• 频繁而又要求精准的项目估算会占用大量的时间和精力，导致软件交付延期。开发人员使用“任务板挪卡”而非考虑周详的设计导致他们造出了一个个“大泥球”，而不是业务驱动下恰当的分离模型。
  
• 开发人员在用户界面和持久层组件中构建业务逻辑。此外，开发人员也经常会在业务逻辑当中执行持久化操作。
  
• 数据库查询会时常出现中断、延迟、死锁等问题，阻碍用户执行时间敏感型的业务操作。
  
• 项目中存在错误的抽象级别，表现为开发人员试图借助过度概括的方案满足所有当下以及臆想出来的未来需求，而不是解决实际而又具体的业务诉求。
  
• 在紧耦合服务群中，当一个服务执行操作时，该服务直接调用另一个服务并引发一个对等操作。这种耦合会经常破坏业务流程和未达成一致的数据，更别提这样的系统会有多难维护了。
  

这一切都似乎发生在“设计无法带来低成本的软件”的观念下。而这时常是出于商业上的简单考虑，软件开发人员并不知道还有其他更好的选择。“软件正在蚕食整个世界”，对你而言重要的是，软件不但可以蚕食你的利润，也可以提供一场利润盛宴。

你一定要明白，臆想出来的“不做设计能省钱”的观念简直是一个谬论，它已经巧妙地愚弄了那些不思考周详设计而只会对软件交付施压的人们。这是因为设计仍然会从每个开发人员的脑海流淌到在键盘上不断敲打着代码的指尖之中，这些设计并不需要来自其他地方的输入，包括业务。以下这句话可以很好地总结这种现象：

关于设计是否必要或是否负担得起的问题根本都没有问到点上：设计是不可或缺的。除了优秀设计就是糟糕设计，根本不存在“不做设计”一说。

尽管 Martin 先生的这句评论并非专门针对软件设计，但这同样适用于我们的技艺，考虑周详的设计同样无可取代。在刚才的情景中，如果一个项目由五名开发人员参与，那么“不做设计”将会产生五种不同的设计。也就是说，在没有任何真正领域专家的协助下，你开发出来的软件将会混杂着五种不同的、虚构出来的、对业务语言的诠释。

事实上：无论承认与否，我们都是在构建模型。

这就好比修建道路。一些历史悠久的道路最开始是跑马车的，经过岁月的碾压最终变得年久失修。为了满足少数人的需要，它们被加入了不明所以的转弯和岔路，并被改造得迂回曲折。在某个时刻，它们会被铲平并且会被重新建设，为的是让越来越多的旅客感到舒适。这些将就凑合的道路到现在还有人路过，不是因为它们设计良好，而仅仅是因为它们存在着而已。如今很少有人能够了解行走在这些道路上别扭不堪的原因。而现代道路都会依据人口、环境以及可预测的流量来规划和设计。两种类型的道路都会被建模。一种模型只是做了最基本、最简单的思考，另一种则最大程度地发挥了聪明才智。软件建模也可以从这两种角度出发。

如果你担心周详的设计会带来高昂的软件开发成本，那么设想一下，将来为了维护甚至修缮一套糟糕设计的软件就需要付出更为昂贵的代价。当我们把软件作为你的公司与其他公司之间的差异，并依靠它带来可观的竞争优势时，尤其如此。

“有效（Effective）”一词和“优秀（Good）”意义相近，它能更准确地表达我们应该在软件设计中努力追求的目标： “有效设计”（Effective Design）。有效设计可以满足商业组织希望借助软件超越竞争者的诉求。它可以驱动企业去思考哪些核心业务必须成为其竞争力，还可以指引构建正确软件模型的方向。

Scurm 中的知识获取是通过不断的试验及协作学习完成的，这被称为“知识付费”（Essential Scrum）。知识永远都不是免费的，但在 《领域驱动设计精粹》中，我将提供一些方法帮你更快地获取它们。

如果你对有效设计的影响仍心存疑虑，别忘了那位曾洞察其重要性的人：

绝大部分人错误地认为设计只关乎外观。人们只理解了表象——将这个盒子递给设计师，告诉他们：“把它变得好看一些!”这不是我们对设计的理解。设计并不仅仅是感观，设计也是产品的工作方式。 ——乔布斯

软件开发中，有效设计最为重要。如果只有一个选择，那么我首推有效设计。

本文节选自 《领域驱动设计精粹》（Domain-Driven DesignDistilled）一书。

本书适用于对快速学习DDD核心概念和主要工具，表面上看最主要的读者是软件架构师和开发者，因为他们是在项目中实践 DDD的人，也跟容易发现DDD的美妙之处。然而，本书同样可以帮助高管、领域专家、经理人、业务分析师、信息架构师和测试人员快速理解这一主题并认识到其独特价值。阅读原文将带你领略DDD大师Vernon的这部新作，它必将成为国内众多团队快速引入和落地DDD的绝佳指导。

该名家名著现已全面上市，可在京东了解更多：https://item.jd.com/12447082.html。