Its Purpose?
This helps people new to a project answer questions about the domain more effectively and where the system fits into it.
Image taken from Kakutani.com’s flickr stream under the Creative Commons Licence.
How Did We Execute It?
We followed domain driven design as much as possible applying several techniques described in the book. We aimed for a Ubiquitous Language, reducing the number of terms for the same thing to a single one. This flowed into the code as well, where domain terms were used for domain classes, and namespaces for related concepts.
We tried to model all of the business processes and rules in a domain layer (the inner most tier on an onion ring model of our system), so that they were easily testable and people knew the first point to look for when answering a question about the domain. A side benefit of this is not tying the domain rules to a particular choice of technology or framework, and makes inconsistencies in the domain much more visible.
Many different factors affected the way in which we coded including aspects from Domain Driven Design, Object Oriented Design (such as encapsulation, responsibility, decoupling and reuse), testability, and readability. Our standards by default exclude comments where possible replaced by representing as much intent as possible in the code itself. We focus on what it does and why. I’ve found “What” tends to be best represented by production code, whilst “Why” is better explained in tests because you can better represent different contexts there.
Given that I’ve been with the project for some time and seen quite a few people flow on and off, I believe that given a handful of system patterns and a high level picture of how it fits together, it’s much quicker to bring people on board. Equipping them with knowledge of where to find information and seek answers for their own questions, you spend less time answering questions and it fits much better into their own mental model.
Why Is It Important?
Following Domain Driven Design and well refactored code brings many more benefits than just effective onboarding (think flexible, adaptable and much more robust and consistent) though I want to specifically focus on its impact on onboarding for the purpose of this entry. Even though these are great development practices, an emphasis on both of these has such a significant positive impact on onboarding of people.
Enabling others to find the answers to their own questions is much more effective because they depend less on others to work out their mental model and help them fill the gaps in that model.
Leave a Reply