我们正在开发一个怪异的大型面向服务的多层应用程序，它必须从头开始设计。现在我们需要开始编程，并尝试组装第一块砖。
问题是从哪里开始？有些人建议我们应该从设计持久数据模型开始，这样可以提供更清晰的视图。这是一个好方法吗？
为 Suirtimed 编辑
这里没有太多的敏捷文化。这是一个 SOA 风格的项目，使用 WCF、SQL Server、实体框架（使用域对象的 POCO 生成器）、ASP MVC 和 Workflow Foundation。我们是一个由 4 名开发人员组成的团队；相当熟练（但不是专家）。
我一直尝试遵循的广泛的总体方法是从设计领域模型开始。这是您的“通用语言”，它将定义业务对象和概念，包含业务逻辑（稍后，当您拥有它时），并且通常是整个系统各个部分使用的通用语言。
这个想法是它应该被所有相关人员理解（或至少可以理解）。例如，其他部门的一些经理不一定会理解关系数据库或任何关于将他部门的数据持久保存在其中的东西。但他确实了解他所在部门的业务流程。他们的方言、他们的概念、他们的互动等等。无处不在的语言是这些群体的共同点。
在此过程中，您应该将依赖项放在首位。最大的一个通常是数据持久性。有一种黄金梦想，即域模型通常不知道持久性或不知道依赖，并且为了分离关注点，这是一件好事。然而，真正的依赖无知会让你陷入困境。您可能会遇到一些严重的性能问题或架构问题，以后需要进行大量重新设计。
因此，偶尔从领域建模中跳出来考虑持久性（以及其他外部依赖项，例如需要使用的外部服务或需要集成的第三方应用程序）。在对域进行建模时，请确保该模型仍然可以正常使用它所需的一切。为了适应依赖项的限制，您可能不得不对无处不在的语言做出一些妥协。
基本上，在设计数据库之前设计域模型。但是在这个过程中不要忘记数据库。
由于数据库将是将企业应用程序连接在一起的关键元素，是的，最好先从它开始，或者至少与应用程序设计同时进行。不要依赖应用程序来确定数据库的结构。您需要设计数据完整性、性能和安全性，而不是面向对象！从至少符合第三范式的数据库设计开始。
数据模型的设计对性能和数据完整性至关重要。而且以后重新设计是比较困难的事情。此外，对于企业产品，您将需要一些仅在数据库中的东西，例如应该从一开始就设计的记录审计。您可能想知道谁对记录进行了更改、更改是什么以及它来自哪个应用程序。这将极大地帮助回滚错误的数据更改并确定导致错误更改的问题的应用程序。
如果您完全从头开始设计，那么是的，您具有定义数据外观的优势。
我只能说，根据我的经验，尽可能多地预先设计数据结构/业务逻辑是有帮助的。
您越深入应用程序，如果数据必须更改，重新调整所有内容就越困难 - 无论您准备多少，数据都会更改，您只需要预先最小化这些更改。
我个人会说，是的，尽可能多地避开数据设计。你不能本末倒置。
我们通常从一些用例开始，以初始化一些用于存储数据的实体。之后，我们尝试进行一些数据库建模并特别寻找实体之间的关系。
如果存在基本数据库模型，我们将开发一个原型并尝试在原型中包含尽可能多的用例。