第一个模型或数据库是什么？
我的问题是软件开发中应该首先考虑什么：数据库模型还是领域模型？或者这些概念是相似的？ 谢谢。
My question is about what should be go first in software developing: database model or domain model? Or these notion are parallels?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这取决于您是数据库人员还是对象人员。每个人都会宣称自己是至高无上的，并说应该先做自己的专业。
两者我都不同意。您应该做的第一件事就是充分了解您的问题。模型和模式将由此产生。
无论你做什么，你都无法摆脱对象关系不匹配的阻碍。对象是基于实例的； SQL 是基于集合的。你仍然会遇到这个问题。
It depends on whether you're a database or an object person. Each one would claim supremacy and say that their specialty should be done first.
I'd disagree with both. The first thing you should do is understand your problem well. The model and schema will flow from that.
You can't get rid of the object-relational mismatch impedence, no matter what you do. Objects are instance-based; SQL is set-based. You'll still have the problem.
首先应该是概念设计（用利益相关者舒服的术语描述问题领域），而模型是基于概念设计的逻辑设计。有一套相当全面的工具和技术可用于根据概念需求导出对象模型。从概念到模式设计的映射很少有普遍熟悉的工具和技术。 （我唯一熟悉的一个很好的方法是对象角色建模。）但是，有一些很好的方法可以使用对象模型来开发模式。所以我更喜欢概念模型而不是对象模型而不是数据模型。
查看问题的另一种方式是，如果您开发数据库，那么应用程序往往会将用户转变为为数据模型提供服务的数据收集代理，从而失去基于用户故事和用例的良好需求的价值（其中第二个似乎变成了 注：令人困惑
的是，ORM（对象角色建模）与 ORM（对象关系映射）无关。
What should come first is the conceptual design (describing the problem domain in terms comfortable to the stakeholders), and the model is a logical design based on the conceptual design. There is a reasonably comprehensive set of tools and techniques for deriving an object model from the conceptual requirements. There are few commonly familiar tools and techniques for mapping from concept to schema design. (The only one I'm familiar with, which is a good one, is Object Role Modeling.) However, there good ways to use an object model to develop a schema. So I prefer conceptual to object model to data model.
Another way to view the question is that if you develop a database then the application tends to turn users into data collection agents serving the data model, losing the value of good requirements based on user stories and use cases (the second of which seem to turn into CRUD.)
Note: confusingly, ORM (Object Role Modeling is unrelated to ORM (Object Relational Mapping).
答案将在很大程度上取决于您正在开发的应用程序类型以及您正在使用的语言/框架。如果您将在数据库中编写大量业务逻辑（如存储过程、视图、触发器），那么首先设计数据库是有意义的。
如果您打算使用一些将域模型映射到数据库的框架（可能还有模式生成，例如 hibernate），那么您将首先编写域类。
The answer will greatly depend on type of application you are developing and the languages/framworks you are using. If you will be writing lot of business logic in database (like Stored Procs, Views, triggers) then it makes sense to first design the database.
If you are going to use some frameworks that map domain model to database (and possibly schema generation, like hibernate) then you will like to write Domain classes first.
设计良好的数据库和对象模型，并利用对象关系映射 (ORM) 层来解决阻抗不匹配问题（这就是它们的设计目的）。
Design good database and object models and leverage an object-relational-mapping (ORM) layer to solve the impedance mismatch (that's what they are designed to do).
这场血仇比海盗与忍者之间的历史还要久远。 :)
在我看来，首先从领域模型开始有助于弥合功能需求和技术设计之间的差距。对象模型比数据模型更好地表示业务数据，并且可以将它们绘制成图表，以便非技术业务分析师和项目经理在项目早期更好地理解。
This blood feud is older than pirates vs. ninjas. :)
In my opinion, and it is just that, starting at the domain model first helps to bridge that gap between the functional requirements and the technical design. The object model better represents the business data than a data model can, and they can be diagramed for better understanding by non-technical business analysts and project managers early in the project.
海盗！忍者！鸡！蛋！
每个项目都是不同的，有时，数据库的设计决定了任务的成功。如今，这种情况相当罕见，因为硬件和软件已经发展 - 但如果您必须存储和计算大量数据，模式可能是您的关键关注点之一。
大多数时候，挑战来自于业务领域。我推荐埃文斯关于该主题的“领域驱动设计”——但我鼓励您首先使用用例或用户故事来捕获业务领域；将它们转化为软件是关键的挑战，如果您和您的同事认为实体关系是最好的，那就去做吧；如果您对类层次结构和职责图更熟悉，那也很酷。
我的印象是，这个行业正在转向物体，而不是桌子——从职业角度来看，这可能是一条出路。
Pirates! Ninjas! Chicken! Egg!
Every project is different, and sometimes, the design of your database determines the success of your mission. It's quite rare, these days, because hardware and software has moved on - but if you have to store and compute huge volumes Of data, the schema may be one of your key concerns.
Most Of the time, the challenge is the business domain. I recommend "domain driven design" by Evans on that topic - but I'd encourage you to capture the business domain first, using use cases or user stories; turning those into software is the key challenge, and if you and your colleagues think best in entity relationships, go for it; if you're mOre comfortable with class hierarchies and responsibility diagrams, that's cool too.
My impression is that the industry is moving to objects, rather than tables - career-wise, that might be the way to go.
领域模型提供了比数据库模型更高的抽象级别。另一方面，数据库模型添加了许多难以直接映射到业务概念的概念（例如数据透视表、外键、视图等）。如果您从数据库模型开始，您会发现自己做出了更多的约束决策，而不是从域模型开始。
The domain model presents a higher level of abstraction than that of the database model. The database model, on the other hand, adds a number of concepts that are harder to directly map to business concepts (e.g. pivot tables, foreign keys, views, etc). If you start by the database model you'll find yourself making a greater number of constraining decisions as opposed to starting with the domain model.