How Domain-Driven Design (DDD) Helps Interviewing Subject Matter Experts (SMEs): the Aggregates
There’s a precise moment when you, as a technical writer, will likely lose control of the information flowing from SMEs: when boundaries among concepts are lost
The more I face complex stuff, the more I discover things would be much more straightforward if shaped with the appropriate language and approach.
Besides, when I discovered the Domain-Driven Design (DDD), I knew everything was already there, just to be learned. Magic!
Boundaries make it possible for consistency
What’s consistency, and why is it so important?
Based on the Cambridge Dictionary, something’s consistent when:
always happening or behaving in a similar way
and
agreeing with something said or done previously
Consistency ensures no contradictions: that’s why it’s crucial.
Contradictions may arise from the topic that SMEs describe as well as from the way they describe it. Both sources of contradictions lead to misunderstandings, and we all know that misunderstandings imply waste, inefficiency, and, eventually, failure.
Boundaries enable saying what’s in and what’s out, and that’s why they are the bricks by which you build consistency: they provide words to state the identity of a concept and what composes it.
In other words, boundaries are the dike that keeps contradictions out of reasoning.
That’s where aggregates come to play.
Aggregates are the building block of thinking
Aggregates work as categories in thinking: they indicate what belongs to an entity and what’s outside it.
Back to Eric Evan’s definition, an aggregate is
a cluster of associated objects that we treat as a unit for the purpose of data changes
This definition is terrific. It roots in a purpose — data changes — and defines the most common mind’s attitude: putting things together.
Grouping things is like focusing with the eyes: it enables understanding through synthesis, turning off the complexity of details through a clear view of the boundaries of things.
Yet, there are many ways of putting things together. To decide which way is your way, you need to state the purpose, which, for aggregates, is preserving consistency through changes.
No aggregates, no smooth modeling
You can model a domain and ignore the aggregate pattern, but you don’t want to miss the opportunity to get a ready-to-use mindset to smooth the modeling endeavor.
Aggregates formalize what’s relevant in a business domain to solve some specific problems of it. You know: there’s no solution without a defined problem. Aggregates are the terms of the problem, and they are its vocabulary.
We all often forget how foundational words are. A model is made up of nothing but words:
- Nouns reveal objects. Some objects are actors, and others are entities.
- Verbs convey commands and events. Commands cause events.
- Adjectives and adverbs play as decorators, like attributes and meta-data. That’s the meta-language that connects different levels of abstraction.
Put together a set of objects that must consistently change to behave as a unity: that’s an aggregate. Besides, an aggregate is a boundary defining what’s inside that unity and outside. What’s inside must change consistently and under the aggregate’s control.
When listening to SMEs, analyze the nouns, verbs, adjectives, and adverbs they use: they are the raw building blocks of the model they — explicitly, but more often implicitly — assume and that you need to understand deeply.
What’s impressive is that DDD provides a ready-to-use way to listen to SMEs because it deems communication as the crucial facet of building software. It deals with communication from business people to engineers, and vice versa, where technical writers are in a central position to facilitate the flow.
No modeling, no communication
SMEs present how a business domain works; they speak about reality: actual people who need to get things done quickly thanks to some software automation.
Aggregates are the foundation of that communication. They incorporate the business language and behavior; they are the composite words of the business domain.
Back to my previous article Distinguishing Problem and Solution: The Domain-Driven Design’s Recipe, aggregates belong to the solution space but are on edge between problem and solution. That’s why they are crucial to modeling and communicating: they describe how things happen by incorporating the logic that transforms commands into events.
Ultimately, what’s the pivotal question you ask SMEs as a technical writer?
How do things happen?
That’s not an oversimplification: that’s a tool to keep simple concepts and dynamics by giving them a consistent and regular shape.
That’s aggregates.
Conclusions
This article is a warm suggestion, nothing more. Many excellent other articles and books — like Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy by Vlad Khononov (non-affiliated link) — present and deeply explain what DDD as a whole and aggregates as a part of it are.
My intent here is to promote the systematic way of thinking that DDD brings to the table and point out that it’s necessary when designing software and exploring and describing it.
I often wrote that it’s all about words. Aggregates show that up. They are the shape of thinking about a system’s behavior because they constitute the building blocks of its grammar. The words, indeed.
My truth: Things are less complex when you write them down!
If you enjoyed my article and found it helpful, please share it and consider following me and subscribing to my new writings!
Not yet a Medium member? Join Medium through my referral link: you’ll support my writing and get into a sea of knowledge!
