7

My question is about what should be go first in software developing: database model or domain model? Or these notion are parallels? Thanks.

Alexandr
  • 1,452
  • 2
  • 20
  • 42

6 Answers6

8

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.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • +1 for pragmatism. The first model of the business domain should be on paper, not as SQL or some class definition. – David Schmitt Apr 22 '11 at 14:02
  • Then after you understand the problem,I think it is good to work on the both at the same time, going back and forth between them. – HLGEM Apr 22 '11 at 14:35
3

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).

dkretz
  • 37,399
  • 13
  • 80
  • 138
2

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).

bdoughan
  • 147,609
  • 23
  • 300
  • 400
  • 1
    Yes +1, design them independently (by separate people if possible), and then work on the ORM. – Matthieu Napoli Apr 22 '11 at 14:02
  • No, ORM does not change the fact that objects are instance-based and relations are set-based. ORM just lets object modelers pretend that it doesn't exist. – duffymo Apr 22 '11 at 14:38
  • @duffymo - Of course an ORM does not change the differences between objects and relations. As you state it does allow object modellers to pretend the difference doesn't exist. So the if an ORM is used the answer to this question is that the object model and database model can be designed independently. – bdoughan Apr 22 '11 at 16:55
  • Don't confuse pretending with reality. I chose the word deliberately. I think it's worth pointing out that stored procedures can also separate objects from schema and should be considered as another way to allow the two to evolve independently. – duffymo Apr 22 '11 at 17:13
  • @duffymo - Agreed an ORM layer does not hide 100% of the difference, but in reality they're pretty good (and getting better all the time). Also as you mention there are other strategies for keeping the models independent. IMHO that should be the goal, design the best models possible and leverage technology to move data between them. – bdoughan Apr 22 '11 at 17:31
  • I think I'm ignorant about "getting better all the time." I'm not aware that Hibernate has changed much in quite a while, for example. Do you have a particular ORM solution in mind when you write that? – duffymo Apr 25 '11 at 09:24
  • @duffymo - In particular I was referring to JPA and the current spec JPA 2.1 (JSR-338). This Java EE spec is driven by a number of ORM solutions including: TopLink/EclipseLink (I lead EclipseLink JAXB) and Hibernate. – bdoughan Apr 25 '11 at 13:06
  • Thank you, Blaise. I'm not aware of the evolution of TopLink (very old) or Hibernate (relatively stable). Can you cite substantial changes? Are they all part of JAXB? – duffymo Apr 25 '11 at 13:49
1

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.

kdabir
  • 9,623
  • 3
  • 43
  • 45
0

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.

maple_shaft
  • 10,435
  • 6
  • 46
  • 74
0

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.

Neville Kuyt
  • 29,247
  • 1
  • 37
  • 52