我的问题是软件开发应该首先考虑什么：数据库模型还是领域模型？或者这些概念是相似的？ 谢谢。
这取决于你是数据库人还是对象人。每个人都会宣称自己是至高无上的，并说应该先做自己的专业。
我都不同意这两个观点。您应该做的第一件事就是充分了解您的问题。模型和模式将由此产生。
无论你做什么，都无法摆脱对象关系不匹配的阻碍。对象是基于实例的； SQL 是基于集合的。你仍然会遇到这个问题。
首先应该是概念设计（用利益相关者舒服的术语描述问题领域），模型是基于概念设计的逻辑设计。有一套相当全面的工具和技术可用于根据概念需求导出对象模型。从概念到模式设计的映射很少有普遍熟悉的工具和技术。 （我唯一熟悉的一个很好的方法是对象角色建模。）但是，有一些很好的方法可以使用对象模型来开发模式。所以我更喜欢概念模型而不是对象模型而不是数据模型。
看待问题的另一种方式是，如果您开发数据库，那么应用程序往往会将用户变成为数据模型提供服务的数据收集代理，从而失去基于用户故事和用例的良好需求的价值（其中第二个似乎是变成 CRUD。）
注意：令人困惑的是，ORM（对象角色建模）与 ORM（对象关系映射）无关。
答案很大程度上取决于您正在开发的应用程序类型以及您正在使用的语言/框架。如果您将在数据库中编写大量业务逻辑（如存储过程、视图、触发器），那么首先设计数据库是有意义的。 如果您打算使用一些将域模型映射到数据库的框架（以及可能的模式生成，例如 hibernate），那么您将需要首先编写域类。
设计良好的数据库和对象模型，并利用对象关系映射 (ORM) 层来解决阻抗不匹配问题（这就是它们的设计目的）。
这种血仇比海盗与忍者之间的历史还要久远。 :)
在我看来，首先从领域模型开始有助于弥合功能需求和技术设计之间的差距。对象模型比数据模型更好地表示业务数据，并且可以将它们绘制成图表，以便非技术业务分析师和项目经理在项目早期更好地理解。
海盗！忍者！鸡！鸡蛋！
每个项目都是不同的，有时，数据库的设计决定了任务的成功。如今，这种情况相当罕见，因为硬件和软件已经发展 - 但如果您必须存储和计算大量数据，模式可能是您的关键关注点之一。
大多数时候，挑战来自于业务领域。我推荐埃文斯关于该主题的“领域驱动设计”——但我鼓励您首先使用用例或用户故事来捕获业务领域；将它们转化为软件是关键的挑战，如果您和您的同事认为实体关系是最好的，那就去做吧；如果您对类层次结构和职责图更熟悉，那也很酷。
我的印象是，这个行业正在转向物体，而不是桌子——从职业角度来看，这可能是正确的出路。
领域模型提供了比数据库模型更高的抽象级别。另一方面，数据库模型添加了许多难以直接映射到业务概念的概念（例如数据透视表、外键、视图等）。如果您从数据库模型开始，您会发现自己做出了更多的约束决策，而不是从领域模型开始。