我们正在开发一个非常大的面向服务的多层应用程序，它必须从头开始设计。
现在我们需要开始编程，并尝试组装第一块积木。
问题是从哪里开始？
有人建议我们应该从设计持久数据模型开始，这将提供更清晰的 View 。这是一个好方法吗？
为 Suirtimed 编辑
这里没有多少敏捷文化。
这是一个 SOA 风格的项目，使用 WCF、SQL Server、 Entity Framework (使用域对象的 POCO 生成器)、ASP MVC 和 Workflow Foundation。
我们是一个由 4 名开发人员组成的团队；相当熟练(但不是专家)。
最佳答案
我总是尝试遵循的总体方法是从设计领域模型开始。这是您的“无处不在的语言”，它将定义业务对象和概念，包含业务逻辑(稍后，当您拥有它时)，并且通常是系统各个部分中使用的通用语言。
这个想法是每个参与者都应该理解(或至少可以理解)。例如，某个其他部门的某些经理不一定会理解关系数据库或任何有关将其部门数据保存在其中的内容。但他确实了解他部门的业务流程。他们的方言、他们的概念、他们的互动等等。无处不在的语言是这些群体共享的共同基础。
在此过程中，您应该牢记您的依赖关系。最大的一个通常是数据持久性。有一种黄金梦想，即域模型通常是持久性无知或依赖无知的，并且为了分离关注点，这是一件好事。然而，真正的依赖无知会让你陷入困境。您可能会遇到一些严重的性能问题或架构问题，这些问题稍后需要进行大量重新设计。
所以偶尔脱离领域建模去思考持久化(以及其他外部依赖，比如需要使用的外部服务或者需要集成的第三方应用)。在为域建模时，请确保该模型仍然可以正常使用所需的一切。为了适应依赖的限制，你可能不得不在无处不在的语言上做出一些妥协。
基本上，在设计数据库之前设计领域模型。但是在此过程中不要忘记数据库。
关于design-patterns - 对数据库模型建模是否是设计复杂的大型企业应用程序的好方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4554925/