To create a logical and physical relational data model, and a class design model, that is flexible and extensible enough to allow applications to evolve without major changes, we must start by modeling business. Specifically, modeling entities and their relationships, along with specialized attributes and associations such as inheritance. The artifact that captures reality in a very close way is the Domain Model.
But unlike the definition available in Wikipedia, I’m focusing on the Rational Unified Process (aka RUP) that says:
“Incomplete business object model, focuses on explaining products, deliverables, or events that are important to the business domain. Such a model does not include the responsibilities people carry.”
Still, this definition is broad and leaves room for many interpretations. According to RUP, incomplete means that we are modeling business partially, without process models or business use cases. As a complement, we have the following definition from Martin Fowler:
“Visual representation of conceptual classes or objects from the real world in a domain of interest.”
Wait, this definition is broad too. To be even more clear, we just represent business entities, their relationships and attributes. The definition of an entity is also from RUP:
“In business modeling, business entities represent objects that business workers access, inspect, manipulate, produce, and so on.”
It’s very important to know that we are modeling business, so it’s the current real world. But with those definitions, we can model anything.
The creation of a domain model is structured in the following steps:
I’m going to detail all steps in one model. The modeling language will be Unified Modeling Language (aka UML) as it is closely related to RUP and have all semantic elements to achieve the desired expressivity level. For the sake of completeness, the steps will include an example in a specific domain described as follows:
In a health sampling area, patients who must take exams are now received on a first-come, first-served basis or by scheduling. Each patient is called by a sample collector, who prepares all the necessary elements according to the patient’s clinical record and their need for tests. These elements are: supplies, tubes and necessary containers, according to the type of examination. For each tube or container used in a sample, the collector labels it to establish its origin and destination. Finally, the samples are delivered for dispatch to the corresponding laboratory, awaiting analysis and results.
Here we can use the category list of conceptual classes to identify them in the domain of interest. This list can be extended as needed.
|Physical or tangible objects||Record, Airplane|
|Specifications, designs or descriptions||Specification of Product, Fly Description|
|Transactions||Sale, Payment, Reservation|
|Transaction details||Sale’s Detail|
|Containers||Store, Canister, Airplane|
|Things in a container||Passenger|
|External systems||Payment Authorization System|
|Facts||Sale, Payment, Meeting, Fly, Landing|
|Processes||Product’s Sale, Seat Reservation|
|Policies and rules||Cancellation Policy|
|Financial, working, contract and legal records||Receipt, Account Book, Contract|
|Financial instruments and services||Credit Line, Stock|
|Handbooks, documents, books, reference articles||Repair Manual|
Additionally, we must apply the cartographer’s strategy:
For instance, our domain model in a clinical context will have the following candidate conceptual classes:
|Physical or tangible objects||Syringe, Vacuum-Extraction Blood Tube, Urine Sample Container, Label, Vacuum-Extraction Blood Needle, Vacuum-Extraction Blood Tube Holder, Scalp Vein Set, Tourniquet, Kidney Dish, Sharp Container, Band-Aid, Cotton Ball, Procedure Gloves, Face Shield, Medical Mask, Goggles, Trash Can, Isopropyl Alcohol Bottle, Sterile Cotton Ball|
|Specifications, designs or descriptions|
|Places||Blood Box, Urine Box, Waiting Room, Internal Laboratory, External Laboratory|
|Transactions||External Laboratory Services Purchase|
|Transaction details||Patient’s Basic Personal Information, Hospital Tributary Identification, Laboratory Exam’s Name|
|Roles||Patient, Sample Collector, Medic, Sample Collection Manager, Statistician|
|Containers||Vacuum-Extraction Blood Tube, Urine Sample Container, Sharp Container, Trash Can, Isopropyl Alcohol Bottle, Bag, Box|
|Things in a container||Blood Sample, Urine Sample, Syringe, Vacuum-Extraction Blood Tube, Urine Sample Container, Label, Vacuum-Extraction Blood Needle, Vacuum-Extraction Blood Tube Holder, Scalp Vein Set, Band-Aid, Cotton Ball, Procedure Gloves, Medical Mask, Isopropyl Alcohol, Sterile Cotton Ball|
|Organizations||Hospital, External Laboratory|
|Facts||Exams Order, Exams Order Entry, Exam Order Entry Status, Patients Schedule, Patients Schedule Entry, Patient Schedule Entry Status, External Laboratory Services Purchase Order, External Laboratory Services Purchase Order Entry, External Laboratory Services Purchase Order Entry Status|
|Policies and rules||Clinical Supplies per Exam|
|Financial, working, contract and legal records||Exams Order, Patients Schedule, External Laboratory Services Purchase Order, Exam Results, List of Daily Exams|
|Financial instruments and services||Stock for the following tangible objects: Syringe (100 units per box), Vacuum-Extraction Blood Tube (100 units per plumavit gravel), Urine Sample Container (100 units per bag), Vacuum-Extraction Blood Needle (50 units per box), Vacuum-Extraction Blood Tube Holder (20 units per box), Scalp Vein Set (50 units per box), Tourniquet (10 units per box), Band-Aid (100 units per box or bag), Cotton Ball (50 units per bag), Procedure Gloves (100 units per box), Medical Mask (50 units per box), Isopropyl Alcohol Bottle (50 units per box), Sterile Cotton Ball (50 units per bag). Others: Critical Stock.|
|Handbooks, documents, books, reference articles|
Now it’s time to diagram the identified entities in a domain model. This can be achieved by using UML class diagram in a simplified way: without data types, qualifiers and visibility indicators. The following rationale applies to representation:
The following figure shows the domain entities represented in a UML class diagram simplified, with associations, attributes and multiplicity:
By creating a domain model we achieve a deeper, better and shared understanding of the domain that is being represented. We can also communicate our ideas and thoughts about that domain thanks to the model. Normally it is a tool that complements very well with user stories or use cases and allows UI prototyping too.
Modeling the domain directs the logical and physical modeling of a relational data model. This can be achieved by following the 8 steps of the algorithm designed by Elmasri Navathe. A good class design model can be diagrammed starting with the domain model, following some steps too and, finally, you have to assign responsibilities using GRASP patterns.