该文比较了软件工程中敏捷和瀑布两个方法，主要是分析了敏捷方法，指出敏捷方法的致命问题：我们们在系统开始时使用敏捷确实节省了分析和定义整个数据模型的时间，但经过一段时间、一年或更长时间后，我们将花费相同或更多的时间来处理糟糕的数据模型或大数据重构。
如果我们在实现需求之前再添加一个阶段，那么可以很容易地避免我们将来可能遇到的这些问题，而不是从一开始就强制完全极端地敏捷。花点时间分析，定义和建模，涵盖项目中的主要重要史诗故事epic stories ，这更其实类似于瀑布式方法+DDD了。
敏捷的方式
现在，每个软件开发人员都知道敏捷宣言中提供的敏捷基础知识，宣言中这些想法可能更抽象，但从现实生活经验看，我们可以定义十二个原则：
- 通过早期和持续交付有价值的软件实现客户满意度
- 欢迎不断变化的需求，甚至是开发后期
- 经常提供可运行的软件（是数周时间而不是数月）
- 业务专家和开发人员之间的密切，日常合作
- 项目是围绕有动力的个人建立的，他们应该受到信任
- 面对面交谈是最好的沟通方式（共址）
- 可运行的软件是前进的主要衡量标准
- 可持续发展，能够保持稳定的步伐
- 不断关注技术卓越和良好的设计
- 简单性 - 最大化未完成工作量的艺术 - 至关重要
- 最好的架构，要求和设计来自自组织团队
- 通常，团队会反思如何提高效率并相应调整
基于敏捷的最常用的方法是scrum，项目应该在一系列迭代的小步骤中完成，这些步骤称为冲刺sprint。一个冲刺应该有一个月的最长期限。最常见的是两周。Scrum的主要目标 - 敏捷是逐步开发软件的，将所有需求分成较小的需求，并在每个sprint上处理其中的一些需求。提出一些小的需求，以便有几个可以适合在一个冲刺sprint中完成。每次冲刺sprint后，都会有一个版本发布，并将其提交给PO进行审核（功能错误等）。
瀑布的方式
瀑布的基本模型流程包含以下几个阶段：
- 软件要求
- 分析
- 系统设计
- 编码和实施
- 测试和验证
- 操作和维护
正确实施敏捷的方法
比较这两种方式，我们可以发现使用敏捷而不是瀑布会更好更可靠。我们不必等待很长一段时间，才能验证我们做的是正确的，通过每次迭代都让客户逐步接受项目。
但是问题来了：由于不喜欢花时间分析和定义整个数据域，提前满足所有需求，以根据项目的实际需求建立整个架构，因为这将耗费他们的时间和金钱。所有需求故事都只在项目开始后定义。将它们分成小的需求，这可以在一个冲刺期间完成，没有无用的工作和努力。
将根据每个新要求，每个新功能或某些错误来定义和创建数据模型。一开始，数据模型将很好地运行服务，需求可以快速完成，因为不存在创建新实体并将其引用到现有实体的问题。而我们实现DDD时，首先是定义数据模型然后实现代码。
经过一段时间以后，通过冲刺建立了一些数据模型，这时需要更改模型的新需求来了，我们将面临越来越多的困难，需要使现有的数据模型适应新的需求。在一瞬间，我们将不得不在模型中做出更大的改变。这样做的主要原因是，当我们实施这些需求时，我们只关注我们在上一个故障单、故事等处理过程中对sprint的需求，而我们并不知道模型对特征需求的需求。
两个解决方案：
- 继续尝试研究我们现在制作的模型。这将使实施我们的新变更更加困难，并且更加耗时。
- 或者在某一时刻停止使用新功能并花时间在数据模型的大型重构上。这需要很长时间才能在项目中使用新功能进行任何高效工作，只需重构。
在这两种情况下，我们的生产力都会低于我们的预期。
如果我们回顾一下我们所做的事情，我们会看到我们在开始时节省了分析和定义整个数据模型的时间，但经过一段时间，一年或更长时间后，我们将花费相同或更多的时间来处理糟糕的数据模型或大数据重构。
如果我们在实现需求之前再添加一个阶段，那么可以很容易地避免我们将来可能遇到的这些问题，从一开始就花时间分析，定义和建模我们必须在项目中涵盖的主要重要的史诗故事，这更类似于瀑布式方法中的DDD。