假设您正在实现一个用户故事，需要从UI（或服务外观）到数据库的所有层进行更改。
你移动的方向是什么？
答案 0 :(得分：2)
我见过这类问题的最佳答案是由Atomic Object人员及其Presenter First模式提供的。基本上它是MVP模式的一个实现，其中（顾名思义）你开始使用Presenter工作。
这为您提供了一个非常轻量级的对象（因为演示者基本上可以将模型中的数据封送到视图，以及从视图到模型的事件），可以直接建模用户操作集。在处理Presenter时，视图和模型通常被定义为接口和模拟，因此您最初的重点是定义用户与对象的交互方式。
我通常喜欢以这种方式工作，即使我没有做严格的MVP模式。我发现专注于用户交互可以帮助我创建更容易交互的业务对象。我们还在内部使用Fitnesse进行集成测试，我发现在构建我的业务对象时为Fitnesse编写灯具有助于将注意力集中在用户对故事的看法上。
但是，我不得不说，当你开始一个失败的Fitnesse测试时，你最终会得到一个非常有趣的TDD周期，然后为该功能创建一个失败的单元测试，然后按照你的方式回到堆栈。在某些情况下，我也在编写数据库单元测试，因此在Fitnesse测试通过之前，还有另一层测试需要编写，失败和传递。答案 1 :(得分：1)
如果可能发生变化，请从前面开始。您可以立即获得股东的反馈。谁知道？也许他们实际上并不知道他们想要什么。观察他们使用界面（UI，服务或其他）。他们的行为可能会激发您以新的眼光看待问题。如果您可以在编码域对象和数据库之前捕获更改，则可以节省大量时间。
如果要求是严格的，那就不那么重要了。从可能是最困难的层开始 - 尽早解决地址风险。最终，这是“更多艺术而非科学”问题之一。它可能是层设计之间微妙的相互作用，可以创造最佳解决方案。
干杯。
答案 2 :(得分：0)
我会自下而上，因为你会快速得到一些工作结果（即你可以在没有用户界面的情况下编写单元测试，但在模型完成之前无法测试用户界面。）
但是还有其他意见。
答案 3 :(得分：0)
我会开始对问题域进行建模。创建表示系统实体的相关类。一旦我对此有信心，我就会尝试找到一个可行的映射来将实体持久化到数据库中。如果您在拥有域模型之前在UI中投入了太多工作，那么之后需要重新使用UI的风险很大。
考虑到这一点，你可能需要对所有层进行一些更新...... =）