Lesson 1

Domain partitioning is a process for dividing a problem domain into cohesive units before proceeding into detailed object design. The problem domain was defined in the first two phases of the project using the use case model, the object model, and the dynamic model. In this module, you will learn how to perform the domain partitioning process using these tools as your primary source. After completing this module, you will be able to:

Complex systems require careful and detailed analysis and design. Throw-away prototyping is particularly well suited to such detailed analysis and design, but system prototyping is not. The waterfall methodologies^[1] can handle complex systems, but without the ability to get the system or prototypes into user's hands early on, some key issues may be overlooked. Although iterative development methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these methodologies tend to devote less attention to the analysis of the complete problem domain than they might if they were using other methodologies.

Domains allow partitioning of systems into collections of components that have some characteristic in common. In this architecture a domain is a scope in which a collection of objects, said to be members of the domain, is associated with some common characteristic; any object for which the association does not exist, or is undefined, is not a member of the domain. A domain can be modeled as an object and may be itself a member of other domains.
It is the scopes themselves and the object associations or bindings defined within them which characterize a domain. This information is disjoint between domains. However, an object may be a member of several domains, of similar kinds as well as of different kinds, and so the sets of members of domains may overlap.
The concept of a domain boundary is defined as the limit of the scope in which a particular characteristic is valid or meaningful. When a characteristic in one domain is translated to an equivalent in another domain, it is convenient to consider it as traversing the boundary between the two domains.
Domains are generally either administrative or technological in nature. Examples of domains related to ORB interoperability issues are:

[1] The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialisation of tasks.