使用什么样的开发流程才能更好实现DDD？不是敏捷！ - ziobrando ·

如何在我们的开发流程中适应领域驱动设计？这是许多与DDD相关的讨论中经常出现的问题。
埃里克·埃文斯（Eric Evans）对流程的描述就是他所说的漩涡模型。..这不是一个单向流程（而是反复循环的开发过程）！

如果您正在寻找结构化的顺序流程，这听起来可能会令人失望，但是如果您同意两个基本原则，那完全是有道理的：

• 学习是瓶颈
• 一个工具将无法讲述整个​​故事。

原型就是建模
编写代码是检查我们的假设是否正确的好方法。归根结底，源代码是最终的模型，并且也提供了很好的反馈。

如何选择我们的流程
漩涡的想法是一种生动的说法：“没有过程，只有反馈循环”，意思是“找到最适合您的方法，选择在您的方案中具有最高投资回报的工具组合”，其中包括您，就个人而言，您的团队和您的组织。
我可以举几个例子来更加精确。

高速单焦点
我喜欢的工作方式是使用Big Picture EventStorming来确保我对系统的最重要部分进行了建模，然后以无拘无束的方式深入研究解决方案。组织刚刚告诉我们，我们正在解决的问题是当务之急，因此我们希望找到不浪费时间的最佳解决方案。
在这种情况下，我需要零或很少的文档准备：我只是探索了整个流程（理想情况下是昨天），理解很生动，我只需要关注解决方案。顺便说一句，专家们正在会议室里，因此，每一个需要的知识都可以触及。

• 包括一些UI线框在内的软件设计事件风暴正在告诉我很多有关事件，边界，策略，命令和读取模型的信息 ...如果您的课程安排得很好，还可以了解更多信息。
• 我们可以使用BDD测试以这种Given ... When ... Then格式快速捕获主要场景，并通过边界示例挑战它们。
• 我们可以开始制作原型，看看是否错过了一些东西。通常在TDD上使用单个构建块。

这里也没有交接（banq注：建模人员与开发人员之间的交接），出于很多原因，交接是错误的，但是在理解问题和实施急需的解决方案之间仅仅是不必要的浪费就足够了。

文档呢？
这要看情况！该文档的用途是什么？

• 如果我们缩短了理解和编码之前的时间，那么事实文档可能是多余的。如果我们今天进行探索并在几个月后进行编码，我们将需要更多的永久性文档（但是在这种情况下，您可能需要解决一个严重的过程缺陷，而不是将补丁制度化）。
• 事实证明之后是另一回事。您应该在特定情况下根据需要记录文档，可能会寻找不在今天的用户。一些行业出于非常充分的理由而对合规性要求非常严格（您不希望有指向某些草图的核反应堆关闭程序）。在这种情况下，文档是您开发工作的重要组成部分，应相应地对其进行处理。

那我的团队呢？
对于您的团队 ……选择取决于您！查找可以为您和您的队友提供最多反馈的工具组合。微调您的工具(墙上的风暴图线框是否足够画的好？还是我们需要展示色彩鲜艳的原型以获得正确的反馈？)，根据对您组织中的人员有效的方法，可以随意删除没有任何优势的工具和实践。
空虚的仪式和仪式很无聊，无聊扼杀了学习。
有时，正确处理错误是最快的学习方法（如果您正确地管理风险）。
学习的瓶颈在于学习是主观的。找到您学习最多的工具组合。
准备在项目生命周期内更改工具和实践。起初有很大帮助，但一旦建立了一套核心实践，可能就没有多大用处。也要为相反的方向做好准备：一些看似无害的维护演变可能需要更深入的思考，也许需要进行另一轮协作建模以预见机遇。

那我的敏捷过程处方呢？
敏捷就是要提高团队效率，而不是减慢团队速度。但是，某些敏捷实施可能会变成高价值的学习型项目的笼子。（banq注：敏捷变成教条后其实是反DDD模式）
迭代是一种以给定间隔对项目状态进行采样的方法-这是一件好事-但它们也用于测量速度，这可能会比较棘手。
如果速度变得太重要（可能对于进度可预测性而言），那么节奏和可重复性就变得至关重要，以确保速度可读。不幸的是，节奏和可重复性也是无聊的关键因素，无聊是众所周知的学习的主要敌人。
有趣的是，低WiP看板实现非常适合惠而浦。低WiP也意味着并行进行的主题较少，因此较高的团队将精力集中在正确的方向上。只要我在学习中取得进步，我就不会在意可预测性。
突破将破坏正确方向的可预测性。;-)
通常，在高价值项目中，您应该准备使用另一套规则：

• 在选择之前先玩更多的选择，
• 当需要大量学习时，故意打破节奏。
• 在探索性时刻降低进度跟踪的优先级（但随时可以在需要时进行控制）。