Object Model in Domain Partitioning

The object model is used in *domain partitioning* to break down a complex system into manageable, cohesive sections based on distinct areas or modules within a business or application domain. This approach helps organize and structure the design, making it easier to develop, understand, and maintain. Here’s how the object model aids in domain partitioning:

1. Identify Domain Areas: Domain partitioning begins with analyzing the business or application to identify key areas or functionalities, known as domains. These could represent different sections of the application, such as "User Management," "Billing," or "Product Catalog" in an e-commerce system. Each domain corresponds to a set of related responsibilities and objects, helping to define clear boundaries.
2. Class Allocation and Responsibilities: In the object model, classes are created to represent entities and concepts within each domain. Classes are then allocated to specific partitions based on their primary responsibilities. This method ensures each domain area is populated with classes relevant to its core purpose, making it easier to manage, update, and understand.
3. Encapsulation of Related Behavior: By grouping related behaviors and attributes into classes within the same domain partition, the object model minimizes dependencies across domains. This means classes that often interact or are interdependent are grouped together in the same partition, reducing the need for excessive cross-domain communication.
4. Hierarchical Relationships and Inheritance: The object model allows for the use of inheritance and specialization within domain partitions. For example, a "Person" class may be the parent for both "Customer" and "Employee" classes in a domain partition focused on "People Management." Hierarchical relationships ensure common behaviors are abstracted at higher levels, while specific behaviors are managed by subclasses, keeping the domain’s structure clean and organized.
5. Associations and Dependencies: The object model represents associations (such as aggregation and composition) and dependencies between classes. Classes that are highly dependent on each other are often placed within the same domain partition to maintain low coupling between domains. This arrangement improves maintainability and isolates changes to a single domain whenever possible.
6. Domain-Specific Rules and Constraints: Each domain partition can encapsulate rules, constraints, and policies specific to its area. For example, a "Billing" domain may have rules around payment processing and transaction validation. Encapsulating these within the same domain ensures that changes or additions are contained, reducing the risk of interference with other parts of the system.
7. Reuse and Flexibility: The object model encourages creating reusable components or utility classes that can be used across multiple domains. For example, a "Logging" or "Notification" utility may be placed in a shared domain partition, making it accessible to other partitions without duplicating functionality. This approach supports code reuse, reduces redundancy, and keeps the model flexible for future updates.

In summary, the object model in domain partitioning brings order to complexity by dividing a system into cohesive, well-defined parts. Each domain encapsulates related classes, behaviors, and rules, reducing interdependencies and simplifying development, testing, and maintenance. The clear boundaries and structured organization facilitate a more modular and scalable system architecture.

Use cases define a goal. To accomplish the goal, the use case needs resources. The use case resources are the objects defined by the classes in the object model. To allocate classes to a domain partition you need to examine resources on two levels:

1. What resources are created or controlled by the domain partition?
2. What resources are referenced by the domain partition but created or controlled elsewhere?

• Creating and controlling resources:
  Every resource object has to be created. The question you need to answer when you attempt to assign objects to partitions is, "Who is responsible for creating the object?" Typically, you should allocate the class that defines the objects to the use cases that create the objects. Usually there are only one or very few use cases that create the same type of objects. Once an object is created it can be accessed by other use cases in other partitions through the database (persistent repository) or any number of object server components. The “creating” and “referencing” use cases do not have to know about each other. Every class in the object model must be assigned to a partition. This process provides one measure of completeness in the transition from analysis to design.
• Referenced Resources:
  When a domain partition requires access to a resource it may either create the resource or look it up. A referenced resource may simply be queried or it may be updated. In a language like Java, this arrangement would look like an imported class. In other words, the class definition resides in another package but is being used in the current package. For this reason, some tools support the use of a different icon for referenced or imported classes.

The following series of images walks through the process of identifying and incorporating into the package the classes that support the selected use cases.

Click the Exercise link below to work on the course project.
In this exercise, you will allocate classes to domain partitions.
Object Model Domain Partitioning - Exercise