Object Model Domain Partitioning - Exercise Result

You entered:

Allocate classes to domain partitions

The object model is used to allocate classes to "domain partitions" by organizing and grouping related classes based on their responsibilities, roles, and relationships within a specific domain. Here’s how this is typically achieved:

Identify Domain Areas: The object model starts with understanding the business or application domain. Key areas or modules within the domain are identified, often representing major functionalities, features, or workflows. For example, in a university management system, "Student Enrollment," "Course Management," and "Faculty Management" could be separate domain areas.
Class Allocation Based on Responsibilities: Classes are allocated to domain partitions based on their primary responsibilities. Each class is analyzed for what it represents in the domain (e.g., a "Student" class, "Course" class, or "Faculty" class) and is assigned to a domain partition that best matches its core purpose. This helps maintain separation of concerns and makes each partition easier to manage.
Encapsulation of Related Behavior: The object model encourages encapsulating related behaviors and attributes within classes. Classes that interact frequently or depend on each other to fulfill a specific functionality are grouped within the same domain partition. This grouping minimizes dependencies across partitions and ensures that related behaviors are contained within a single domain area.
Hierarchical Relationships and Inheritance: Domain partitions are sometimes structured hierarchically to represent inheritance or specialization relationships. For example, if there’s a generic "Person" class that both "Student" and "Faculty" inherit from, all three might belong to a "People Management" partition, with each subclass handling specific behaviors related to its type.
Associations and Dependencies: The object model represents associations and dependencies between classes using relationships (such as aggregation, composition, and association). These relationships help determine which classes should be within the same partition or linked across partitions. Classes with strong dependencies on each other are often placed in the same partition to reduce coupling across domains.
Domain-Specific Rules and Constraints: The object model incorporates domain-specific rules, constraints, and policies, which influence how classes are grouped. For instance, in an e-commerce domain, "Order" and "Payment" classes might be placed in the same partition to ensure that payment processing rules and order handling are managed within a single cohesive module.
Reuse and Flexibility: Domain partitions created in the object model are often designed with flexibility and reusability in mind. Classes that have cross-domain applicability or are utility-based (like "Logging" or "Notification") are placed in their own shared partitions to allow reuse across multiple domain areas without redundancy.

By organizing classes into domain partitions, the object model enables better modularity, maintainability, and scalability in system design. This approach also supports clear boundaries, making it easier to extend or modify specific parts of the system without impacting unrelated domains.

Recommended solutions for the assignment of classes in the object model to the domain partitions are slided below.

1) The Sales subsystem includes all of the use cases that the customer and agent will use to find the Show the customer wants to attend, select the seats to sit in, and purchase the seats. During the sales process, the customer will create a Purchase and issue Tickets using a Credit Card. They may also use the Sales system to refund Tickets they have purchased in a previous session.

2) The first step in preparing for sales is the setup of the physical facility. We have only identified one use case, "Maintain Auditorium Floor Plan," that handles the arrangement of the possible seating locations within the auditorium. This use case maintains the three classes of objects that define the physical facility, Auditorium, AuditoriumFloorPlan, and Seat. Once these objects have been defined, they become available for use in subsequent subsystems.

3) The Price Planning subystem/partition includes all of the use cases involved in the creation and maintenance of prices and discounts. The classes included in the subsystem are those classes that represent the objects that describe the prices and discounts. Different combinations of prices and discounts are configured into PricingPlans. The PricingPlans may then be applied to any number of Shows by using the Show Pricing subsystem.

4) Before the customers can use the system to purchase Tickets, they need to obtain access to the application. It correlates to a typical security system where users are defined to the system and are provided with a unique identification and password.

5) The Event Management subsystem is responsible for creating and maintaining Events. Each Event may provide a unique EventFloorPlan. However, in order to set up an Event, this subsystem requires access to objects that have been created in another subsystem. These classes are shown as gray and would correspond to imported classes in Java.

6) Show Management extends the work completed in Event Management by adding Shows for the scheduled Events. It relies on the fact that the Events and their related EventFloorPlans are completed and available for use. Note that the Event, EventFloorPlan, and Seat classes belong to other subsystems but are referenced here in Show Management.

7) Show Pricing is unique from the subsystems described so far in that it does not create or maintain any new objects. It uses existing objects defined in other subsystems and creates links between them. A PricingPlan is assigned to a Show, and specific PriceTiers within the PricingPlan are assigned to groups of ShowSeats within the Show.