Chapter 5. Modularization of domain models

 

This chapter covers

  • Modularizing your domain models
  • Exploring a detailed case study of a domain model split into modules
  • Understanding how modules aggregate to bounded contexts
  • Using an advanced pattern of modularization, the free monads

Whenever you think of a large model, it’s always helpful to think in terms of smaller units within the whole. That’s how our cognitive abilities work as well. Instead of trying to understand up front how all the details of an entire banking system work, it’s easier to think about the smaller parts, such as customer account management, portfolio management, reporting services, and the back-office model. These are also fairly independent subsystems speaking different ubiquitous languages and may well have separate data and domain models. Even within each of these subsystems, there are functionalities that are too complex to understand as a whole.

When I talk about modularization, I mean decomposing such a model into smaller modules that group semantically related behaviors. Each module has algebra that’s published to clients and one or more implementations that are carefully protected from inadvertent coupling with the client code. This chapter explores the modularization of domain models and how to use abstractions to split your model into composable modules.

Figure 5.1 shows the flow of this chapter’s topics. This schematic will guide you to selectively choose your topics as you sail through the chapter.

5.1. Modularizing your domain model

5.2. Modular domain models—a case study

5.3. Type class pattern—modularizing polymorphic behaviors

5.4. Aggregate modules at bounded context

5.5. Another pattern for modularization—free monads

5.6. Summary

sitemap