应该先做哪个？领域模型还是数据模型？ [关闭]答案

【问题标题】：Which should be done first? Domain model or Data Model? [closed]应该先做哪个？领域模型还是数据模型？ [关闭]
【发布时间】：2013-07-14 16:16:10
【问题描述】：

大家好，假设我有一个新项目，即库存系统。我将使用Java。我去我的客户那里收集一些需求，在我收集它们之后，我将对这些需求进行建模。我应该先做什么？我的类图/域模型？还是数据模型？为什么？我真的很想你对此发表意见。您在现实世界中从事软件开发的工作是什么？

我使用这些技术：Java、Hibernate(ORM)、Scrum(方法)、postgresql(数据库)

【问题讨论】：

应首先基于对应用程序需求和规范化的理解来创建数据库 ERD 设计。 ERD 是基础。
但是您不认为ERD仅用于数据存储吗？你不想先对问题域建模吗？您的运营会发生什么？你的对象的行为？也许您会在数据建模期间错过这一点。数据模型接近域模型，只是您的行为/方法不存在并且实体仅用于数据。如果您想发送电子邮件或短信，该怎么办。如果你分层会发生什么？
不，我不认为 ERD 是“仅用于数据存储”。正如我所说，正确的 ERD 是数据驱动应用程序开发的基础。 OO 设计方法如果忽视数据规范化的规则，就会产生混乱。
感谢蒂姆的意见。会尝试在某些项目上这样做。并且反其道而行之。看看情况如何。再次感谢。 =)
@Tim 数据标准化与 ER 建模无关。当您从 ER 模型切换到关系模型时，就会考虑规范化问题。

标签： oop database-design model domain-driven-design

【解决方案1】：

不要先做任何一个。并行创建域（对象）模型和 ER 模型。它们应该非常相似，只是域模型关注数据和行为，而 ER 模型只关注数据。

但是，您需要非常小心，以避免许多从业者，甚至是专家，都会陷入的陷阱。这就是分析和设计之间的混淆。你的领域模型和你的 ER 模型都应该是分析模型而不是设计模型。这意味着它们描述了问题和要求，而不是您在设计解决方案时要添加的功能。

特别是，您在本论坛中看到的许多 ER 图实际上都是关系数据模型，即使它们使用 ER 表示法。而且它们结合了外键等设计特性，并且不局限于信息需求中固有的特性。

未能在设计开始之前相当准确地确定需求是大型项目失败的主要原因。在小型项目中，没有那么多。

【讨论】：

谢谢沃尔特。是的，分析模型部分是正确的。那么为什么不首先做领域模型呢？因为它同时拥有数据和行为。然后数据模型将由域模型制成，并进行一些调整，例如非规范化..等，这样您就不会加倍工作..您怎么看？
@John Patrick Po：就先到先得而言，您不能对尚未标准化的内容进行非规范化:-)
哦..我的意思是你的域模型可能与数据模型不同..说在你做了域模型之后然后制作数据模型然后在那里做一些非规范化。
你的领域模型是分析模型还是设计模型？
它仍然是一个分析模型 walter。

【解决方案2】：

我的 2 美分...

数据往往比代码寿命更长、更稳定，最终也更重要。所以你的方法应该以数据为中心。如果您正确地构建和规范化数据（ER 图是执行此操作的重要工具），其余的自然会随之而来。

【讨论】：

【解决方案3】：

IMO 你绝对不应该首先考虑你的数据模型。

原因是您的领域层可以满足所有业务需求。
您的域层必须是不可知的。它不应该与任何特定的技术实现相关联，也不应该引用任何类型的框架。它应该是自包含的并且可以单独工作。在设计领域层时，不要考虑持久性，甚至不要考虑数据的显示方式。如果您需要存储数据的方法，或从特定 UI 容器（如 Session）收集信息的方法，请使用 Interfaces。

在设计数据模型时，您与将用于存储数据的 RDBMS 绑定在一起。您将考虑如何构建架构以有效地存储和访问数据。但问题是业务部门并不关心您的查询的执行情况。

尽可能推迟 UI、框架、数据库等关键决策总是一件好事。这样您就可以只关注业务需求。

【讨论】：

领域层是分析，对吧？因此，您不会“设计”它。你会发现它。
ER 模型也与 DBMS 无关。事实上，对于实现是否是相关的，它是不可知的。
感谢您的意见。你的权利沃尔特。你发现它然后你设计它。但是 ER 模型不包括行为.. 你不认为你应该使用 oo(UML) 或结构化(DFD) 方法来做第一个领域的分析模型吗？包括行为（例如计算净成本……等）。你怎么看？