Understanding Domain Models and Their Role in Software Design

Concept and Role of Domain Model

Domain model is a visual representation of concepts or real‑world objects within a problem domain, also known as a conceptual model or analysis object model. It focuses on understanding the business domain, extracting key concepts and their relationships, essentially drawing a class diagram that reflects the domain.

It helps align team members’ understanding, guides database design, system functionality, and development, acting as a bridge from requirements to implementation.

When building a domain model, the emphasis is on essential features rather than exhaustive attributes or methods; over‑detailing can obscure the big picture.

Simplified Expense Reimbursement Example

Two Main Tasks for a Domain Model

Define key attributes and behaviors of classes.

Define associations between classes.

Defining Class Attributes and Behaviors

Use a design tool to add a class; visibility symbols: - private, # protected, ~ package (default), + public.

- 表示private
# 表示protected
~ 表示default,也就是包权限
+ 表示public

Defining Inter‑Class Relationships

UML defines six relationships: Generalization, Realization, Association, Aggregation, Composition, Dependency.

Generalization

Represents inheritance between classes or interfaces. Symbol: hollow triangle + solid line.

public class A { }
public class B extends A { }

Realization

Class implements one or more interfaces. Symbol: hollow triangle + dashed line.

public interface A { }
public class B implements A { }

Aggregation

Weak “has‑a” relationship; the part can exist independently. Symbol: hollow diamond + solid line.

public class A { private B b; public A(B b){ this.b = b; } }

Composition

Strong “contains‑a” relationship; the part’s lifecycle depends on the whole. Symbol: solid diamond + solid line.

public class A { private B b; public A(){ this.b = new B(); } }

Association

Very weak relationship, often represented by a plain line; can be shown by a member variable.

public class A { private B b; public A(B b){ this.b = b; } }

Dependency

Even weaker than association; any usage of one class by another (parameter, return, local variable) creates a dependency. Symbol: dashed arrow.

public class A { private B b; public A(B b){ this.b = b; } }
public void func(B b){ ... }

Model Simplification

Strict UML distinctions increase learning cost and add little value for business communication; in practice, aggregation, composition, and association are often merged into a simple association with multiplicity.

Conclusion

Creating a domain model is simple in appearance but complex in process, requiring iterative refinement with input from architects, domain experts, and stakeholders.

Common beginner mistakes: placing the system itself inside the model when it should be external, and unclear concept boundaries leading to misplaced relationships.