Building Blocks of Domain Driven Design Part 1

A Navigation Map of Model Driven Design

Isolating the Domain

To apply our best thinking,we need to be able to look at the elements of our model and see them as a system. We must not be forced to pick them out of a much larger mix of objects.We need to decouple the domain objects from other functions of the system.

Layered Architecture

Software programs invovle design and code to carry out many different kinds of tasks. They accept user input,carry out business logic,access database,communicate over the network,display information to users and so on.

When the domain related code is diffused through such a large amount of other code, it becomes extremely difficult to see and reason about. Superficial changes to the UI can change business logic. To change a businedd rule may require meticulous tracing of UI code,database code or other program elements.Implementing coherent model driven objects becomes impractical.

Creating complex programs that can handle very complex tasks calls for separation of concerns and the best way is through layered architecture

The essential principle is that any element of a layer depends only on other elements in the same layer or on elements of the layer beneath it.

Each Layer can be described as:

Layers Interaction

Layers are meant to be loosely coupled, with design dependencies in only one direction. Upper layers can use or manipulate elements of the lower layer by calling their public interfaces.When lower level needs to communicate upward they can rely on architectural patterns like Callback or Observers.

The architectural pattern for connecting the UI to the application or domain layer can happen via the Model View Controller Patterns.

The infrastructure layer usually does not initiate action on the domain layer.Being below the domain layer, it should have no specific knowledge of the domain it is serving.Such technical capabilities are most often offered as Services.

As an example,if an application needs to send an e-mail,some message-sending interface can be located in the infrastructure layer and the application layer elements can request the transmission of message.This decoupling gives some extra versatility. The message sending interface might be connected to an email sender or a fax sender.This way the application layer is kept narrowly focused on when to send the message rather than on how.

Not all infrastructure comes in the form of Services callable from higher layers.Some technical components are designed to directly support the basic functions of other layers(such as providing abstract base class for all domain objects) and provide the mechanism for them to relate, this is more common in MVC like frameworks and these have an impact on the design of the other parts of the program.

Judicial Use of the Architecture Frameworks

Although the best architectural frameworks try to solve complex techincal problems but these framework can straightjacket application developers either by making too many assumptions that constraint domain design choices or by making the implementation so heavyweight that development slows down.

Judiciously applying only the most valuable of framework features reduces the coupling of the implementation and the framework,allowing more flexibility in later design decisions.

The Domain layer is where the Model Lives

The domain model is a set of concepts.The domain layer is the manifestation of that model and all directly related design elements. The design and implementation of business logic constitute the domain layer.

Isolating the domain implementation is a prerequisite for domain driven design

Next Part will cover how Entity,Value Objects and Services are designed and associated.