How to Create a Domain Model

Articles by Bala Paranj

Creating a domain model itself could become a separate book. For a brief overview, here are the steps that you can follow to create a domain model.

Step 1:

Interview the customers and end users to learn about the particular domain that you have to model. Find out how they want to use the system. Focus on business processes and not on data. Focus on gathering information about the domain not on requirements. Listen and take notes. There is no need to be formal at this stage.

Source for domain objects:

a) Customer's organization charts.
b) Departments and employees having well-defined roles and responsibilities supporting the business processes. These are the roles in your domain model.

Step 2:

Identify packages by grouping items that are independent of each other.

Step 3:

For each business process, identify participating objects and assign responsibilities.

Step 4:

Examine each responsibility and see if any other information and operations are needed. When you discover the new information and operations, check to see if it can be allocated to one of the existing domain objects. If this is not possible then you have found a new domain object, group all the related data and operations together in this object. If you are stuck get the help of the domain expert to give a good name to this new object.

Step 5:

Testing the Domain Object Model

Create test cases from the business functions and run them against your domain model. Note down the trouble/vague areas and focus on these during the next iteration of steps 1 through 4.

REMEMBER: Our aim is not to come up with a perfect domain model but it must be a useful and effective communication tool and a good starting point for the design phase. Stop the iteration when you find that the test result shows that the domain model does solve the problems that we were aiming to resolve.

QUICK AND DIRTY METHOD:

If your domain has a RDBMS then you can approach the DB admin and use tools that can take the ER model and convert them into a business domain model. Remember this bottom-up approach to domain modeling will not result in a good domain model. Therefore use this model as your first stab at creating the domain model and iterate through steps 1 to 4 till the testing condition passes. Guideline - Aim for a simple domain model that will solve the given problem. After implementation you can go back and change the domain model to include the new information that you will discover. If you are interested in learning more, refer the book: Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

Reference: Enterprise Java Programming with IBM WebSphere by Kyle Brown, Gary Craig, Greg Hester et al.

OOAD skills for the real world projects

Study Guide - Object Oriented Analysis and Design with UML