Question

…what’s next?

After you defined what actors do what actions, which way do you go? Do you model the database or do you prefer to start with the classes?

I thought the better approach was to start with a class-like modelling diagram, to focus on relationships between objects.
This has proven to be wrong because I went too deep in detailing classes and, even if the system “seemed to work”, when I went to the database modelling, everything just would not fit naturally in the positions I chose in the previous phase.

I read about people saying that one should put application logic into a database and leverage its speed in retrieving data, opposed to building large objects in memory that are queried and provide abstraction of the underlying database.
I always thought that the db is there to store my data and provide a fast way to access it. But maybe I’m wrong, I mean, do I really have to build a database which has inside the same logic I would put on a group of classes? Isn’t the database lacking the tools to achieve this?

I think I’m failing in identifying the right point where to start, if I choose to start with the database I find it hard to not just think of it as a “place to store my data, let’s do app logic on a higher level” thing, if I start with classes the database ends up looking like an unnatural representation of classes, i feel the sensation of missing something important, something like not assigning the right purpose to the right tool.

How do you deal with this?
When it comes to decide whether to start with modelling the db or the classes, in your experience, what kind of approach has proven to lead to a natural and clean implementation ?

Thanks in advance

Answer 1

I’ve had success using Robustness Analysis.

This article focuses on robustness
analysis, which involves analyzing the
narrative text of use cases and
identifying a first-guess set of
objects that will participate in each
use case, then classifying these
objects into three types:

1. Boundary objects, which actors use in communicating with the system.
2. Entity objects, which are usually objects from the domain model
   (the subject of “Driving Design: The
   Problem Domain,” Jan. 2001).
3. Control objects (which we usually call controllers because they
   often aren’t real objects), which
   serve as the “glue” between boundary
   objects and entity objects.Figure 1
   shows the visual icons for these three
   types of objects.

The entity objects are the ones that (usuallly) end up in the database/

On mapping between classes and the database, I would recommend S.Lott’s article on “The ORM Problem” (he’s also a participant on StackOverflow