Domain Partitioning  «Prev  Next»
Lesson 1

Domain Partitioning | Systems Design

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:
  1. Identify the resources used for domain partitioning
  2. Perform domain partitioning using use cases
  3. Explain how package diagrams may be used to model domain partitions
  4. Assign analysis classes to domain partitions
  5. Test the domain partition for completeness
  6. Identify and define dependencies between partitions

Combining DFD Fragments to Create Event-Partitioned System Model

Data Flow-diagram
Data Flow Diagram

System Complexity

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.

SEMrush Software

Definition of a Domain

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. Referencing domain the scope of an object reference.
  2. Representation domain: the scope of a message transfer syntax and protocol.
  3. Network addressing domain: the scope of a network address.
  4. Network connectivity domain: the potential scope of a network message.
  5. Security domain: the extent of a particular security policy.
  6. Type domain: the scope of a particular type identifier.
  7. Transaction domain: the scope of a given transaction service.
[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.

Ad Domain Driven Design