2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- March 22, 2017
- Bits and Pieces
In his book, Domain Driven Design, Eric Evans said that there really is no such thing as complexity, complexity happens when we diverge from our models, when we use metaphors inconsistently, and I tend to agree. Very involved systems can be easy to understand as long as they adhere to an appropriate set of metaphors.
So how do we find the right metaphors for the problem at hand?
It’s actually easy, because we naturally think in metaphors to begin with. Any problem we express is already defined in some form of abstraction or metaphor, so our primary task is to group different pieces together in ways that make sense to us. We do this by simply asking, “What is the same about these different pieces?” and “What is different about them?”
If we think from the user’s perspective we can often get a good sense of the domain model and then drive down to implementation. Design patterns can be used to group concepts in ways that support our goals.
I have an architectural pattern I use related to this that I called “the three layer DIP” (DIP stands for dependency inversion principle). The application or domain layer is the top level, below that is the services layer and below that is the platform layer. The idea is that the domain layer only makes calls to the services layer and the services layer only makes calls to other services or the platform. For many kinds of applications this is a good framework to work within because it makes the domain model clear at the application layer.
The metaphors we use in an object-oriented system are composed of objects. Every object in the system should have its own perspective in the world and should know only enough to accomplish its specific tasks. Separating out perspectives in software gives us the ability to hide different parts of the system so we can make changes without those changes rippling out into other parts of the system. This limiting of knowledge gives software the ability to be more changeable.
Of course, metaphors mean nothing to a computer but the primary goal of writing software isn’t to make a computer do something, that’s secondary. The primary goal of writing software is to communicate our designs to other developers. Since the dawn of civilization, metaphors have been one of the most powerful ways to communicate ideas. Incorporating metaphors in our software designs helps us communicate complex ideas in our code.
Previous Post: « Perspectives
Next Post: Beyond Waterfall Software Development »