Sketching up the classes and attributes
When you are collecting information from clients or are brainstorming which attributes a class should collect, draw the domain diagram with classes that have open sides, so you won't be limited by space.
Don't spend too long in creating a domain diagram. Draw out what you think will be collected and name the attributes you think will be needed. Then edit what you have done. Then get feedback from your colleagues and clients.
Only show what you need
It's best to show only relevant information on a domain diagram. When discussing the diagram with clients, leave off information that won't concern them, like the PK or an ID.
When you go to create the database, filling in the technical info will be useful, so include it for yourself or for your technical team.
The condominium's domain diagram
In this example, I'll expand the example of the condo's domain diagram to include other entities associated with the building and the apartments.
Here are a list of condo by-laws that I'm following for this diagram:
Apartments can have more than one owner, but must have at least one owner.
A car can have more than one owner.
Dogs can spend the night in only one apartment, stray dogs are not allowed in the building, apartments do not need to have a dogs and can house up to 4 dogs.
Cats cans be fed by up to 5 apartments and people who are allergic to cats can own an apartment (Which I'll translate to mean that not every apartment needs to have a cat). Apartments can have up to 8 cats (eek!), and stray cats are allowed (remind me not to move in here!).
The condominium complex contains several buildings. Each building contains a minimum of 15 units.
Employees work in one building.
Only condo owners can have parking places but condo owners don't need to have a car and if they have a car they don't need to park it in the parking lot.
So let's make this orthogonal and clean up the crossing lines.
With this diagram I can go to the group and ask if I have the right connections between classes and find out if my names are correct.
Now let's add in the attributes that I want feedback on:
To finish the UML domain diagram, I'll add the cardinality between the tables to show the relationships.
Now I'm going to create the Physical Data Model that shows information that I'll need when I create the database, like the primary and foreign keys. Instead of the specific cardinality, I'll just put a short hand of an arrowhead pointing to the one side of a one-to-many relationship. On all the many sides of one-to-many or many-to-many, I'll put a crow's foot.
Lastly, in addition to the Primary Keys (PK) and the Foreign Keys (FK) for the "regular tables," for the association tables (a.k.a. junction tables) we take the primary keys from the two tables that it is connecting and make a column for each.
Now that we've created are UML Domain Diagram and a Physical Data Model, next we need to test our schema!