建模数据库模型是设计复杂和大型企业应用程序的好方法吗？

Question

我们正致力于一个面向服务的大型多层应用程序，必须从头开始设计。 现在我们需要开始编程，并尝试组装第一块砖。

问题是从哪里开始？ 有人建议我们应该从设计持久数据模型开始，这将提供更清晰的视图。这是一个好方法吗？

编辑已完成

这里的敏捷文化并不多。 这是一个SOA样式项目，使用WCF，SQL Server，实体框架（使用POCO生成器用于域对象），ASP MVC和Workflow Foundation。 我们是一个由4名开发人员组成的团队;技术合理（但不是专家）。

Answer 1

我总是试图遵循的广泛的整体方法是从设计领域模型开始。这是您的“无处不在的语言”，它将定义业务对象和概念，包含业务逻辑（稍后，当您拥有它时），并且通常是系统各个部分使用的通用语言。

这个想法是每个参与者都应该理解（或至少可以理解）。例如，某些其他部门的经理不一定会理解关系数据库或其他任何关于在其中保存部门数据的事情。但他确实了解他所在部门的业务流程。他们的白话，他们的概念，他们的互动等。无处不在的语言是群体共同的共同点。

在此过程中，您应该将依赖关系放在首位。最大的一个通常是数据持久性。有一个金色的梦想，领域模型通常是持久性 - 无知或依赖 - 无知，并且为了分离关注点，这是一件好事。然而，真正的依赖性无知会让你陷入困境。您可能会遇到一些严重的性能问题或架构问题，需要在以后进行大量的重新设计。

因此，偶尔从域建模中脱离思考持久性（以及其他外部依赖性，例如需要使用的外部服务或需要集成的第三方应用程序）。在为域建模时，请确保模型仍能正常运行所需的一切。你可能不得不在这里和那里对无处不在的语言做出一点妥协，以适应依赖的局限性。

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

Answer 2

由于数据库将是将企业应用程序连接在一起的关键元素，因此最好首先从它开始，或者至少与应用程序设计同时进行。不要依赖应用程序来构建数据库。您需要设计数据完整性，性能和安全性而不是面向对象！从数据库设计开始，至少在第3范式中。

数据模型的设计对性能和数据完整性至关重要。以后重新设计是比较困难的事情。此外，对于企业产品，您将需要一些仅在数据库中的内容，例如记录审核，这应该从一开始就设计。您可能想知道谁对记录进行了更改，更改的内容以及来自哪些应用程序。这将极大地帮助回滚不良数据更改并确定哪些应用程序导致了导致错误更改的问题。

Answer 3

如果您是从头开始设计，那么是的，您可以定义数据的外观。

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

您进入应用程序的深度越大，如果数据必须更改，重新调整所有内容就越困难 - 无论您准备多少数据，数据都会发生变化，您只需要预先尽量减少这些更改。

我个人会说，是的，尽可能多地获取数据设计。你不能把车放在马前。

Answer 4

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

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