« Spring Framework Reference - Chapters 1 and 2 | Main | Chapter 3 [Java's Technological] Crown Jewels »

Architectural Improvement by use of Strategic Level Domain-Driven Design

Basically Domain-Driven design can be divided into three areas:


  • Basic building blocks – Addresses how the domain is separated from technology by use of a layered architecture, combined with practical object oriented design patterns.
  • Sophisticated models – Addresses how the software is aligned with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight.
  • Strategic design – Addresses model integrity and management of complexity in large systems. Strategic design provides three core building blocks:

    • Context mapping
    • Distillation
    • Large scale structures


Article


1. Introduction


Company that is the focus of the paper has embraced Enterprise Architecture as one of its means to better align development of corporate IT systems with business priorities and strategies.


Found that our Enterprise Architecture did not provide the tools needed to address key concerns when
designing and integrating large scale software intensive systems. While enterprise architects focus on business processes, functions and information concepts, software architects have to focus on boundaries and interfaces. As the work with our Enterprise Architecture correlated in time with our adoption of Domain-Driven design [3], we discovered that the strategic part of Domain-Driven design provided the needed mechanisms.


Enterprise Architecture (EA) identifies the main components of the organization, its information systems and the ways in which these components work together in order to achieve defined business objectives. The components include staff, business processes, technology, information, financial and other resources required by the business to achieve its objectives Enterprise Architecture is based on a holistic view rather than an application-by-application view. Most enterprises choose to do
their Enterprise Architecture work according to the practices defined by available frameworks tailored to reflect the architectural principles, standards and reference models defined by the individual enterprise. The frameworks typically provide an architectural lifecycle process and a set of views supporting the different stakeholder interests: business process, information, functions and technical infrastructure.


1.2 Domain-Driven Design



Domain-Driven design is a philosophy whose focus is the intricacies of the domain and where the objective is to make these
intricacies explicit in the domain model and its implementation in code. Domain-Driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. The primary source for these principles is Eric Evans book.


Basically Domain-Driven design can be divided into three areas:


  • Basic building blocks – Addresses how the domain is separated from technology by use of a layered architecture, combined with practical object oriented design patterns.
  • Sophisticated models – Addresses how the software is aligned with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight.
  • Strategic design – Addresses model integrity and management of complexity in large systems. Strategic design provides three core building blocks:

    • Context mapping
    • Distillation
    • Large scale structures



2. Context Mapping


A context map is a drawing that documents modelling contexts and their relationships. Large systems contains multiple modelling contexts, therefore we have depicted the modelling context of interests, not the applications or information systems that implement the different contexts.


3. Distillation


Distillation is about separating the important from the less important. Ideally it should be possible to identify the problem
area that motivates development of this actual software. That part of the domain is called the core domain. To be able to keep the core as small as possible, some domain related functionality should be moved out of the core, allowing us to let our most
skilled people focus on the core.


moved out functionality


  • Supporting Domains
  • Generic Sub-Domains

4. Large Scale Structures


Context map itself become complex and unmanageable. There are two elements from the large-scale structures that have proven valuable:

  • the principle of evolving order
  • the use of responsibility layers