对于设计复杂且大型企业应用程序，建模数据库模型是否是一个好的方法？

Question

我们正在开发一款超级大的面向服务的多层应用程序，需要从头开始设计。现在我们需要开始编程，并尝试组装第一批代码块。

问题是从哪里开始呢？ 有些人建议我们应该从设计持久化数据模型开始，这样会提供更清晰的视图。这种方法可行吗？

编辑为Suirtimed：

这里没有太多敏捷文化。 这是一个SOA风格的项目，使用WCF、SQL Server、Entity Framework（使用POCO生成器生成域对象）、ASP MVC和Workflow Foundation。 我们是由4名开发人员组成的团队；技能相当不错（但不是专家）。

- uzul

---

你能提供更多关于团队规模、技能和技术限制的信息吗？敏捷和瀑布是方法论的两个极端，SOA和ERP风格的应用程序则是耦合/架构的两个极端。在着手数据模型之前需要考虑许多因素。同时还存在对象关系不匹配的挑战。 - Demitrius Nelon

好的，我编辑了更多的信息。 - uzul

Answer 1

我始终遵循的大体方法是先设计领域模型。这是你的“通用语言”，它将定义业务对象和概念，包含业务逻辑（稍后，在你拥有它时），并通常是系统各个部分共用的通用语言。这样，每个参与者都能理解（或至少能够理解）。例如，某个部门的经理不一定会理解关系数据库或任何关于将他们部门的数据持久化的信息。但是他确实了解他们部门的业务流程、他们的术语、概念、互动等。通用语言是各组共享的共同基础。

在此过程中，你应该时刻牢记你的依赖关系。最大的依赖通常是数据持久性。在分离关注点的目的上，有一种黄金的理想，即领域模型对持久性或依赖性一事无知。然而，真正的依赖不知道会让你陷入困境。你可能会遇到一些严重的性能问题或架构问题，需要以后重新设计。

因此，偶尔跳出领域建模，考虑持久性（以及其他外部依赖项，例如需要使用的外部服务或需要集成的第三方应用程序）。在对领域进行建模时，确保该模型仍然能够与它需要的一切正常工作。你可能不得不在通用语言的某些地方做出一些妥协，以适应依赖性的限制。

基本上，在设计数据库之前先设计领域模型。但在这个过程中不要忘记数据库。

- David

---

这么短的时间写得很好！当它适合业务时，我也是DDD的粉丝。 - Demitrius Nelon

Answer 2

由于数据库将成为连接企业应用程序的关键元素，因此最好首先从数据库开始或至少与应用程序设计同时进行。不要仅依赖应用程序来确定数据库应如何结构化。您需要为数据完整性、性能和安全性进行设计，而不是面向对象编程！从至少处于第三范式的数据库设计开始。

数据模型的设计对于性能和数据完整性至关重要，并且重新设计起来更加困难。此外，对于企业产品，您将希望某些仅在数据库中的内容，例如记录审计，这些内容应该从一开始就进行设计。很可能您想要知道谁更改了记录，更改是什么以及它来自哪个应用程序。这将有助于大大减少回滚错误数据更改并确定导致错误更改的应用程序的问题。

- HLGEM

Answer 3

如果您是从零开始设计，那么是的，您有定义数据外观的优势。

根据我的经验，尽可能多地设计数据结构/业务逻辑是有帮助的。

随着应用程序的深入，如果数据必须更改，重新调整所有内容将变得越来越困难 - 而且无论您做多少准备，数据都会发生变化，您只需要尽量减少这些变化。

我个人认为，是的，请尽可能多地设计数据。你不能把车放在马前面。

- picus

Answer 4

通常我们会从一些用例开始初始化一些用于存储数据的实体。之后，我们尝试进行一些数据库建模，并特别关注实体之间的关系。

如果基本的数据库模型存在，我们将开发一个原型，并尝试在原型中包含尽可能多的用例。

- Mariusz