What is the first model or database?

Question

My question is what should be the first in software development: database models or domain models? Or are these concepts parallels? Thanks.

Answer 1

It depends on whether you are a database or an object person. Each of them claims to be superior and says that their specialization should be performed in the first place.

I would not agree with both. The first thing you need to do is understand your problem well. The model and circuit will flow from this.

You cannot get rid of the resistance of object-relational inconsistencies, no matter what you do. Objects are instance based; SQL is set-based. You will still have a problem.

Answer 2

Develop good models of databases and objects and use the object-relational mapping (ORM) layer to solve the impedance mismatch (which they are designed to perform).

Answer 3

The answer will largely depend on the type of application you are using and the languages ​​/ frameworks you use. If you will write a lot of business logic in a database (for example, Stored Procs, Views, triggers), then it makes sense to create a database first. If you intend to use some frameworks that map a domain model to a database (and possibly generate a scheme, such as hibernation), you first need to write domain classes.

Answer 4

The first should be a conceptual design (describing a problem area in conditions convenient for interested parties), and the model should be a logical design based on a conceptual design. There is a fairly complete set of tools and methods for obtaining an object model from conceptual requirements. There are several well-known tools and methods for mapping from concept to schema. (The only one I know is good is modeling the role of objects.) However, there are good ways to use the object model to design the circuit. Therefore, I prefer the conceptual model of the data model object.

Another way to address the issue is that if you are developing a database, the application seeks to turn users into data collection agents that serve the data model, losing the value of good requirements based on user stories and use cases (the second of which seems to turn into CRUD. )

Note: vaguely, ORM (Object Role Modeling is not related to ORM (Relational Object Mapping).

Answer 5

This bloody feud is older than pirates against the ninja. :)

In my opinion, that’s how, starting with a domain model, it helps to bridge this gap between functional requirements and technical design. The object model better reflects business data than the data model, and can be schematized for better understanding by non-technical business analysts and project managers at an early stage of the project.

Answer 6

Pirates! Ninja! A hen! Egg!

Each project is different, and sometimes the design of your database determines the success of your mission. This is quite rare these days because hardware and software have migrated, but if you need to store and compute huge amounts of data, a circuit may be one of your key problems.

In most cases, the task is a business domain. I recommend Evans based on domain design on this topic, but I would recommend that you first capture a business domain using use cases or user stories; turning them into software is a key task, and if you and your colleagues think best of all in dealing with entities, go for it; if you're just comfortable with class hierarchies and responsibility charts, that's cool too.

I got the impression that the industry is moving toward objects, not tables - in terms of a career, this might be the way to go.