Chapter 6: Domain Model Design and Implementation

In Chapter 5, the business tier interfaces exposed to the presentation tier enabled us to create an implementation for realizing the use cases identified by the packages GreaterCause Site Administration, Manage Campaigns, and Search NPO. The business tier interfaces, explained in detail in Chapter 7, employ the session fa ade pattern that is implemented using either stateless or stateful session beans. These session beans encapsulate business logic, which in turn employs domain entities. Domain entities are real-world things and concepts that are part of the problem domain. Domain modeling is the task of discovering these entities and defining their relationships in the context of the problem domain. The discovery of domain entities and their implementation is the focus of this chapter. Basic EJB concepts like home, remote, and local interfaces are not covered in any detail in this chapter. Readers are urged to review the basic material from excellent tutorials and examples available at java.sun.com. The EJB 2.0 specification also has a wealth of material; rather than reproduce this information, we suggest specific sections to read from the EJB 2.0 specification in the context of the material being discussed.

Discovering Domain Objects

Domain modeling involves identifying objects that represent the persistent state of the system. This does not imply that there exists a one-to-one mapping between domain objects and entity beans (or any other object persistence technology). This is because domain objects may represent a conceptual thing that may require services of other entities. The domain objects encapsulate logic that acts upon the domain objects. This logic is aware of the relationships between domain objects and the rules enforced for manipulating the state of the object. Therefore, one must clearly distinguish between logic that resides in the domain objects and the logic that resides in the business tier (business tier is the topic of Chapter 7).

From the Site Administration and Manage Campaigns use case packages described in Chapters 1 and 2, we infer the following requirements for the persistence state of the application.

• The Site Administrator will create the registration information for portal-alliances and NPOs, a portal-alliance administrator will modify the portal-alliance profile, and an NPO administrator will modify the NPO profile. A PortalAlliance and NPO object can provide the encapsulation for accessing and manipulating registration and profile information.

• Portal-alliance and NPO administrators are authorized to access and modify related portal-alliance or NPO profiles. An Admin object can provide us with this association. Although each administrator can be embedded in the PortalAlliance or the NPO domain object, we have chosen to separate the Admin object with the anticipation that in the future the Admin object may have many-to-one relationship with either the PortalAlliance or the NPO domain object.

• Campaigns are created by the portal-alliance administrator. A portal-alliance administrator creates portal-specific campaigns, i.e., each Portal-Alliance domain object is associated with a Campaign domain object. Each campaign will also be associated with an NPO object. A Portal-Alliance object can encapsulate the access mechanisms for portal-alliance–specific campaigns.

From the preceding discussion, we define the domain model shown in Figure 6-1. We assume that readers have the knowledge of UML and object-oriented analysis and design, therefore we do not explain those concepts here. Normally, the practice adopted during domain modeling is to first create an analysis-level class diagram, which we continue to refine as we walk through our requirements expressed in the use cases, and consulting with domain experts to validate the domain model. The problem domain of our sample application is limited in scope, as such we have gone straight to the design-level domain model. We also assume that the domain objects will be implemented as entity beans with container-managed persistence. We continue our discussion on the domain model and its implementation in the section "Implementing the Domain Model." Please note that although the methods on each of the domain objects are identified in Figure 6-1, in reality these methods are discovered incrementally during analysis, design, and implementation of the domain objects, as well as during the design and implementation of business objects that employ the services of these domain objects. Generalization relationships, associations, and multiplicity are discovered in a similar fashion.

Relationships in the Domain Model

The following is a discussion of relationships, roles, and multiplicity identified on the domain model in Figure 6-1.

Figure 6-1: Domain model for Site Administration and Manage Campaigns use case packages

Tip

When creating the domain model, we need to capture all the relationships, roles, and the multiplicity for each side of the relationship. This information is essential for configuring the deployment descriptors. Deployment descriptors are discussed later in the chapter.

• Admin-NPO The relationship between Admin and NPO objects is represented by an association Admin-NPO. This relationship is unidirectional, implying that the Admin interface can access NPO and not the other way around. This directionality is manifested by the getNpo and setNpo accessor methods in the Admin interface. These accessors are defined in the deployment descriptor using the cmr-field-name element whose value is "npo". The relationship is supported in the database using a foreign key field in the ADMIN table to reference the NPO object. We observed in Chapter 5 that an NPO administrator's login username is used for determining the associated NPO object. Using the Admin-NPO relationship, the corresponding getNpo accessor is used for retrieving the associated NPO object. Domain objects will be accessed in the business tier session beans described in Chapter 7.

• Admin-PortalAlliance The relationship between Admin and PortalAlliance objects is represented by an association Admin-PortalAlliance. This relationship is unidirectional, implying that the Admin interface can access PortalAlliance and not the other way around. This directionality is manifested by the getAlliance and setAlliance accessor methods in the Admin interface. These accessors are defined in the deployment descriptor using the cmr-field-name element whose value is "alliance". The relationship is supported in the database using a foreign key field in the ADMIN table to reference the PortalAlliance object. We observed in Chapter 5 that a Portal-Alliance administrator's login username is used for determining the associated PortalAlliance object. Using the Admin-PortalAlliance relationship, the corresponding getAlliance accessor is used for retrieving the associated PortalAlliance object.

• PortalAlliance-Campaign The relationship between PortalAlliance and Campaign objects is represented by an aggregation relationship PortalAlliance-Campaign. This relationship is unidirectional, implying that the PortalAlliance interface can access Campaigns and not the other way around. This type of relationship represents a "has-a" relationship, meaning that the PortalAlliance object has objects of the type Campaign. This directionality is manifested by the getCampaigns and setCampaigns accessor methods in the PortalAlliance interface. These accessors are defined in the deployment descriptor using the cmr-field-name element (for container-managed relationship) whose value is "campaigns". The aggregation relationship is implemented as a Collection. This is apparent from the getCampaigns accessor method that returns a Collection. The corresponding cmr-field-type element in the ejb-jar.xml deployment descriptor also declares the Collection type. The relationship is supported in the database using a foreign key field in the CAMPAIGN table to reference the PortalAlliance object. This relationship is utilized for retrieving a Collection of Campaigns associated with a given Portal-Alliance.

• Campaign-NPO The relationship between Campaign and NPO objects is represented by an association Campaign-NPO. This relationship is unidirectional, implying that the Campaign interface can access NPO and not the other way around. This directionality is manifested by the getNpo and setNpo accessor methods in the Campaign interface. These accessors are defined in the deployment descriptor using the cmr-field-name element whose value is "npo". The relationship is supported in the database using a foreign key field in the CAMPAIGN table to reference the NPO object. This relationship is utilized for retrieving the NPO associated with a given Campaign.