• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part Two: Domain Model / Physical Model

 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok we all know the story. The Domain Model represents business concepts. It doesn't consider things like database normalisation. I consider the role of architect to consider things like database normalisation. Do you?
If so, what is a good way of communicating the changes you'd like make to the physical (database) view?

Discuss...



 
Mihai Lihatchi
Ranch Hand
Posts: 138
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would consider the DB design the job of the DBA. For some projects a database is not required (very few though) and database design is not what I would trust the architect alone to do.
At least were I work it's the DBA that makes the design together with the developers. He is the expert in database not us .. at least not me .

Also yes in theory you should have a normalized database but what about connections to Object Databases or tools such as the Google App Engine DataStore ?
I suggest keeping the design of the classes as connected to the domain model as possible (people lost points over this before) and to abstract away the actual type of data storage. Using JPA helps from this point of view.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic