DDD - Modelling the Domain - Modules

Software systems could become very complex with a large domain model which makes it overwhelming to see the whole picture. The concept of a Module is a design element in many programming languages (in Java they are called Packages and in C# Namespaces) to divide code for managing complexity and assisting in code reuse. Typically, programming language textbooks promote modules mainly as a code organization tool.

On the contrary, Domain-Driven Design raises the importance of modules by considering them part of our model and using them to divide concepts (Evans, 2003). As Evans (2003) puts it “there should be low coupling between modules and high cohesion within them”. The last phrase is very familiar and is the cornerstone of object-oriented programming, that is low coupling between classes and high cohesion within them (Martin, 2009). Although, the role of modules is self-evident, many application frameworks direct developers in grouping code technically and not conceptually, e.g. by placing all interfaces in a single module, all classes that deal with business logic in another module, all classes that deal with data access in another module and so on.

DDD Modules should have meaningful names that are part of the Ubiquitous Language (Evans, 2003). In addition, modules should evolve in parallel with the code elements that are contained and not remain static, i.e. we might have to refactor modules because our conceptual view is different by the introduction of new concepts in the domain model (Evans, 2003; Vernon, 2013).

In the Python programming language, the highest level organisational unit is called a Module (Lutz, 2013). In fact, any file that contains Python functions, classes, data etc is a module which could import and use other modules. Thus, a Python Module and a DDD Module are matching one to one.

References

  • Evans, E. (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston: Addison-Wesley.
  • Lutz, M. (2013) Learning Python. Beijing: O'Reilly.
  • Martin, R. (2009) Clean Code: A Handbook of Agile Software Craftsmanship. Boston: Prentice Hall.
  • Vernon, V. (2013) Implementing Domain-Driven Design. Boston: Addison-Wesley.

This post is an excerpt of my MSc Thesis titled "Applying Domain-Driven Design in Python - designing a self-hosted Read-it-Later service" (January 2014).

This article was updated on

Related post

DDD - Modelling the Domain - Services

When designing a Domain Model the prominent modelling paradigm is objects and as a result we are mapping concepts i.e. nouns to DDD building blocks such as Entities and Value Objects. The behaviour associated to those concepts is mapped to methods using verbs. However, there are domain specific functions that we would like to define in the model but cannot be attached into an existing Entity or Value Object (Evans, 2003). Instead of forcing foreign operations into domain objects, Evans (2003) introduced the concept of Domain Services.

DDD - Modelling the Domain - Value Objects

There are elements of the Domain Model without any conceptual identity which are typically used to characterise Entities (Evans, 2003). Those elements are called Value Objects and their significance is often neglected (Vernon, 2013). Examples of Value Objects are: Zip Code, Order Number, Phone Number, Money, Currency, Date, Date Range, E-mail Address, URL etc. Value Objects express domain concepts and are part of the Ubiquitous Language (Evans 2003; Vernon, 2013).