Week 12 – Relating Design Patterns to the Model

Discussion led by Charandeep Kumar

Apologies for the slight delay in getting this thread started — it’s been a busy weekend. This week, we’re diving into Chapter 12: Relating Design Patterns to the Model.

For me, this chapter felt like a crucial bridge between the abstract world of domain modeling and the concrete world of implementation patterns we use every day. It addresses a question I think many of us have implicitly wondered about: when is a “design pattern” just a technical tool, and when does it become a meaningful part of the domain model itself?

What really stood out was Evans’s argument that a pattern becomes a true domain pattern only when it reflects a concept from the domain. Its name and structure should become part of the UBIQUITOUS LANGUAGE.

The examples he chose made this crystal clear:

• STRATEGY isn’t just a way to swap algorithms; it becomes a POLICY when those algorithms represent real business rules, like a “cheapest route” policy versus a “fastest route” policy. The pattern itself is modeling a choice that exists in the business.
• COMPOSITE isn’t just for building tree structures; it models a genuine part-whole hierarchy in the domain, like a large shipping route that is itself composed of smaller routes.

This chapter feels like it equips us to make more conscious design choices, ensuring our patterns serve the model first and foremost.