MODULES | Domain Model | Domain Layer

What are Modules In Domain Driven Design

Projects, Name Spaces, Folders are used to Package the related things together in all layers and tiers of Onion Arch.

Modules, also known as Packages:

Components with high cohesion should be packaged together. 

Modules are defined by business dependencies, not by the technical architecture.

Example: The Bill Aggregate and the Bill Repository should be put into the same module, as they are very tightly coupled.

Aggregates

• Are used to decompose, organize, and increase the readability of the domain model.

• Namespaces, an implementation of modules, can be applied to reduce coupling and increase cohesion within the domain model.

• Enable readers to quickly understand the design of a model.

• Help to define clear boundaries between domain objects.

• Encapsulate concepts that can be understood independently of each other.

• They operate on a higher level of abstraction than aggregates and entities.

Modules, also known as Packages:

Components with high cohesion should be packaged together. 

Modules are defined by business dependencies, not by the technical architecture.

Domain-Driven Design. Modules & Aggregates

by Jose on October 31, 2016

Modules

The modules are containers of elements that allow us to organize our domain. Technically named as packages or namespaces . The main objective is to decouple and organize the elements depending on the context to which they belong. Following the obicuous language at all times .

Module naming conventions for the model and submodules

Normally and if the company has a domain name on the internet , the main module will start with com . Followed by the name of the organization.

The next module name segment identifies the local Bounded Context where the module or element container is hosted.

It is not recommended to use the commercial names of the products of the organization in the names of modules or submodules since these can change over time and sometimes does not bear a direct relation with the responsibility of the Bounded Context to which it belongs. It is preferable to identify the name of each Bounded Context according to the responsibility of the team. The objective is to reflect the obicuous language of the organization.

Module

Modules that are stored within the model are so-called manifested containers for a specific interrelated group of objects in the domain. 

Their goal is to weaken the connections between the classes within multiple modules. 

From a DDD perspective, modules are non-formal or generic modes. 

Their name selection is a function of ubiquitous language.

You need to design loosely bound modules because it simplifies the support and refactoring of design patterns and concepts. 

If bounding is necessary, you should focus more on acyclic dependencies between peer modules.

 (Peer modules are modules that are located on the same functional layer and have similar value in the project.) 

Modules shouldn’t be designed as a model’s static concepts because they need to be modified depending on objects they organize.

There are certain rules of module name selection. 

Module names are used to depict the organization's hierarchical structure. 

The names’ hierarchy usually starts from the organization's name that is responsible for module development. Like this:

Hide   Copy Code

com.bankingsystems

The next module name segment identifies bounded context. The name of this segment should follow after the name of bounded context. Like this:

Hide   Copy Code

com.bankingsystems.pfm

Then, you have a modifier that identifies the module of a given domain:

Hide   Copy Code

com.bankingsystems.pfm.domain

You can place all the modules into the domain section:

Hide   Copy Code

com.bankingsystems.pfm.domain.account
  <<Entity>>BankingAccount
  <<ValueObject>>AccountId

Design patterns that are stored outside of this model are named according to architecture. Within the context of a well-known multi-layered architecture, the naming would be the following:

1. com.bankingsystems.resources
2. com.bankingsystems.resources.view (user interface layer (view storage))
3. com.bankingsystems.application.account (application layer (submodule of application services))

Modules are used to aggregate bounded objects within the domain and are separated from unbound or loosely bound objects. 

Bounded contexts often do wrap several modules because they bundle/bound all the concepts into a single model if there are no clear borders between multiple contexts.

MODULES (AKA PACKAGES)

Everyone uses MODULES, but few treat them as a full-fledged part of the model. Code gets broken down into all sorts of categories, from aspects of the technical architecture to developers’ work assignments. Even developers who refactor a lot tend to content themselves with MODULESconceived early in the project.

It is a truism that there should be low coupling between MODULES and high cohesion within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn’t just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion).

Therefore,

Choose MODULES that tell the story of the system and contain a cohesive set of concepts. This often yields low coupling between modules, but if it doesn’t look for a way to change the model to disentangle the concepts, or an overlooked concept that might be the basis of a MODULE that would bring the elements together in a meaningful way. Seek low coupling in the sense of concepts that can be understood and reasoned about independently of each other. Refine the model until it partitions according to high-level domain concepts and the corresponding code is decoupled as well.

Give the MODULES names that become part of the UBIQUITOUS LANGUAGE. MODULES and their names should reflect insight into the domain.