问带有服务层和存储库层的ASP.NET MVC，接口应该在哪里定义？

EN

我正在为一个包含存储库层和服务层的.NET MVC应用程序确定一个相当简单的分层体系结构。我已经找到了一些相当清晰和简单的例子，特别是www.asp.net，以及这里的一些问题和答案，但我正在寻找一些更简单的东西，适合于小型应用程序，但使用不同的项目，以使人理解。我链接到上面的示例将存储库和服务作为Models命名空间中的类。对于我来说，这还不足以清楚地说明这一点。

对于实现接口IRepository的存储库，我有一个单独的项目。服务有一个独立的项目，它实现IService并接受IRepository (构造器注入)。该服务实现IService。对于这个示例，控制器实例化服务就足够了，还不需要IoC容器。可以将其视为理解最佳架构实践的中间步骤，是逐步构建以包括依赖注入和可能更多层的序列的一部分。

问题是，我应该在哪里定义IRepository和IService？当然，服务和存储库项目都需要引用它们。因此，很明显，它们应该在服务和存储库项目引用的另一个项目中定义。如果是这样，那么一个好的命名约定是什么？像XXXXContracts这样的？

同样，对于在表示层、服务层和存储库层之间传递的数据模型，是否可以接受所有层都引用一个名为XXXXModels的单独项目？我知道在某些情况下，在服务层和存储库层之间传递的模型可能与在服务层和表示层之间传递的模型不同，但原理是相同的。

我在这里找到了类似问题的答案，但它们往往涉及比我在这里概述的更复杂的架构。我希望实现一个非常简单和清晰的两层说明，可以看作是上面的一两个步骤，引用数据层并在控制器中具有业务逻辑，仅此而已。我知道有一个强有力的、有效的论据支持直接使用成熟的最佳实践，但并不是每个人都适合一下子实现这种跳跃。