Domain Model VS Design Model

Why is the domain model not suitable for or intended to be implemented directly in software?

A domain model will provide visual representation of the classes within the domain, the basic relationships between the domain classes, and any key attributes of the classes. However, since the domain model is used by all parties involved including the customer any details related to actual design or implementation are left out. This means that while the model can be used to describe or discuss the behavior of domain classes, no actual behavior is contained within the domain model. Without behavior there is no way to directly implement the domain model into the software, since everything in the model is essentially a placeholder to be used for data when implementing in the software itself.

 

Can you give a high-level example of the differences between the conceptual classes found in the domain model and the functional classes found in the design/data model?  What are the differences?  Please use a specific domain/design model (not from course content or book).

I've been trying to find examples and a better explanation of what this means to understand it better, but material seems to be rather limited. Hopefully I am understanding this correctly. I'm basing a lot of this on an example I found here: http://www.cs.gordon.edu/courses/cs211/AddressBookExample/

The conceptual classes in the domain model represent the classes and their generalized relationships with each other. The functional classes in the design/data model represent how those relationships actually work, without the actual technical code that facilitates the interactions.

So, if you were building an address book the domain model might say:

  • Address book - relates to entry/people
  • Entry/People - relates to name, address, phone
  • Name - attributes: firstname, lastname
  • Address - attributes: number, street, city, state, zip
  • Phone
  • Database - relates to address book and entry/people
However the design model:
  • Address book - creates new entry or displays existing entry, sorts by name, address, or phone, stores entries in database, retrieves entries from database
  • Entry/people - contains name, address, phone, allows these fields to be created, deleted, or changed.
  • Database - stores entries including specific attributes
The design model is going to spell out how everything works together, how things should be connected, and how they actually interact with each other. This may include more classes than the domain model because there may be more classes necessary to perform the requested tasks than detailed in the domain model since they are specific to the technical design of the application. The actual responsibilities of the classes should also be determined and laid out in this step. The address book object is responsible for keeping track of and displaying people objects, the database is responsible for storing data related to objects, people objects are responsible for displaying the attributes associated with the person, a comparator object is responsible for sorting the address book, etc.