假设我们正在实现一个用户故事，该故事要求从UI(或者服务外观)到DB的所有层都进行更改。

我们朝哪个方向移动？

• 从UI到业务层再到存储库再到DB？
• 从数据库到存储库再到业务层再到UI？
• 这取决于。 (什么 ？)

解决方案

我会自下而上，因为我们会很快得到一些工作结果(即，我们可以在没有用户界面的情况下编写单元测试，但是只有在完成模型后才能测试用户界面)。

不过，还有其他意见。

我将开始对问题域进行建模。创建代表系统实体的相关类。一旦对此感到有信心，便会尝试找到一种可行的映射，以将实体持久存储到数据库中。如果我们在拥有域模型之前在UI中进行了过多的工作，则存在很大的风险，那就是我们需要在此之后重新处理UI。

考虑到这一点，我们可能仍然需要对所有层进行一些更新... =)

如果可能会发生变化，请从头开始。我们可以立即获得股东的反馈。谁知道？也许他们实际上并不知道他们想要什么。看着他们使用界面(UI，服务或者其他)。他们的行为可能会激发我们以新的眼光看待问题。如果我们可以在对域对象和数据库进行编码之前捕获更改，则可以节省大量时间。

如果要求很严格，那么它就不那么重要了。从可能是最难解决的风险的层开始。最终，这是"更多的是艺术而不是科学"的问题之一。层设计之间的微妙相互作用可能会产生最佳解决方案。

干杯。

我看到的关于此类问题的最佳答案是由"原子对象"人员及其" Presenter First"模式提供的。基本上，这是MVP模式的实现，在该模式中(顾名思义)我们是从Presenter开始工作的。

这为我们提供了一个非常轻巧的对象(因为演示者基本上是在那里将数据从模型存储到视图，并将事件从视图存储到模型)可以直接为一组用户操作建模。在Presenter上工作时，通常将View和Model定义为接口并进行模拟，因此最初重点是定义用户与对象的交互方式。

我通常喜欢以这种方式工作，即使我没有执行严格的MVP模式。我发现专注于用户交互可以帮助我创建更易于交互的业务对象。我们还使用Fitnessit内部进行集成测试，我发现在构建业务对象时为Fitnesse编写夹具有助于使事情集中于用户对故事的看法。

但是，我不得不说，当我们从不合格的Fitnesse测试开始，然后为该功能创建一个不合格的单元测试时，我们会遇到一个非常有趣的TDD周期，然后逐步备份堆栈。在某些情况下，我还在编写数据库单元测试，因此在Fitnesse测试通过之前，还有另一层测试需要编写，失败和通过。