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
  • DFD Fragment 1
  • DFD Fragment 2
  • DFD Fragment 3
    • 3 Produce class list
      • Inputs:
        • Student
        • Offered course
        • Course enrollment
      • Outputs:
        • Class list to Faculty member

Combine DFD fragments to create diagram 0**
  • Diagram 0
    • 1 Schedule course
      • Input:
        • Schedule data from Academic department
    • 2 Enroll student
      • Inputs:
        • Enrollment request from Student
        • Schedule
      • Output:
        • Course enrollment
    • 3 Produce class list
      • Inputs:
        • Student
        • Offered course
        • Course enrollment
      • Outputs:
        • Class list to Faculty member

Analysis
  1. DFD Fragments: The top section of the image shows separate Data Flow Diagram (DFD) fragments, each representing different processes or parts of the system, which include individual tasks like producing a class list. Each fragment appears to handle a specific data flow, isolated from other components until combined.
  2. Process 3 - Produce Class List: Fragment 3 is detailed, showing "Produce class list" as the main process with three inputs (Student, Offered course, and Course enrollment) and one output (Class list for Faculty member).
  3. Combining DFD Fragments: The diagram indicates that individual DFD fragments are combined to create "Diagram 0," representing a higher-level system overview.
  4. Diagram 0 - Overall System: The lower part of the image shows Diagram 0, a cohesive data flow diagram integrating multiple processes:
    • Process 1 - Schedule Course: Receives input from the Academic department and produces scheduled data.
    • Process 2 - Enroll Student: Takes Enrollment request from the Student and integrates the Schedule to produce Course enrollment.
    • Process 3 - Produce Class List: Uses data from Student, Offered course, and Course enrollment to generate a Class list for Faculty member.
  5. Entities and Data Flow: Diagram 0 showcases data flow among various entities (Academic department, Student, Faculty member) and processes, illustrating how data moves through the system from input to output.

This structure highlights a systematic approach to DFDs, illustrating both the isolation of specific processes in fragments and their integration into a comprehensive system diagram.
Domain Driven Design

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.
  • 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.

SEMrush Software