There are many ways of partitioning an application. Usually, what we do is actually classify the code according to some criteria and organise the code following that criteria.
This chapter of the book explores four criteria:
- Functionality vs. Domain;
- Conway’s Law;
- Geographic constraints;
- Cultural concerns.
All in all, the idea is that we partition our codebase with long-term local autonomy in mind, according to history, standards and conventions, experience and common sense (Coplien 2010, p.91).
Functionality vs. Domain
The first partition we make is Frontend/Backend, or in other words Behaviour/Domain, or yet in other words what the system does versus what the system is. In practice, we can see this for example when we have a client/server architecture.
Technique 1
Focus on the essence of the system form (what the system is) without being unduly influenced by the functionality that the system provides (what the system does).
Coplien 2010, p.89
Another way of partitioning the code is by its change rate, which is in line with one of Robert C. Martin packaging principles, The Common Closure Principle: Classes that change together, belong together.
Technique 2
Separate the components of your architecture according to their differing rates of change.
Coplien 2010, p.90
Conway’s Law
Conway’s Law tells us that, for whatever reason, the structure of the codebase tends to align with the structure of the organisation, and changes in the organisation will be reflected in the code base structure.
Technique 3
Focus on the form of what the system is, partitioning it so that each part can be managed as autonomously as possible.
Coplien 2010, p.90
Technique 4
The dominant consideration in supporting team autonomy is the locality with which common changes are handled.
Coplien 2010, p.91
Technique 5
Let the human considerations drive the partitioning, with software engineering concerns secondary.
Coplien 2010, p.92
Technique 7
Be attentive to the opportunity to use product lines and use this insight to bolster support for domain partitioning where possible.
Coplien 2010, p.96
The idea is that we should partition the codebase in a way that matches the organisation partitioning so that we can build on human interactions, team cohesion and autonomy to reduce waste and increase the ability to respond to change.
Geographic constraints
Don’t partition the codebase with partitions that would result in having teams that are not co-located. Teams that are not working in the same physical space will have one extra barrier in comunication, which is key in team dynamics and productivity.
Technique 6
Be attentive to domain partitioning. In particular, don’t split a domain across geographic locations or across architectural units.
Coplien 2010, p.95
Culture concerns
The world and the companies themselves are full of different cultures and they can be problematic if their differences are ignored, because of hiccups in communication and different visions of the world.
It is, therefore, important to minimise problems originating in cultural differences and instead build on those differences to gain different insights by building multicultural teams, for many of the same reasons that Lean and Scrum advocate cross-functional teams (Coplien 2010, p.100).
@hgraca 