Village-Driven Design #1
Village problems, software solutions.
Software people love the word “driven”. You see it in job titles and in books: Test-Driven Development, Domain-Driven Design, Event-Driven Architecture. The word before “Driven” tells you what the design follows. Test-driven means the tests come first. Domain-driven means the business comes first.
I am starting an article series. So why I named “Village-Driven Design” Because in this series, the village drives the decisions. When I want to explain a hard software idea, I look for the same problem in village life. Villages have been solving these problems for hundreds of years, with paper, memory and trust. Software does the same job with code.
Here are six “driven” designs you will see often:
- Domain-Driven Design (DDD): Build the software with the words and rules of the business.
- Test-Driven Development (TDD): Write the test first, then the code that passes it.
- Behavior-Driven Development (BDD): Describe what the user does and what should happen, in plain sentences.
- Event-Driven Architecture: Parts of the system talk by sending events, like “payment received”.
- Data-Driven Design: Make decisions with data, not with guesses.
- API-Driven Design: Agree on the contract between systems before you build either side.
Each one asks a simple question: what is the most important thing here while designing systems?
Welcome to “Localhost” Village
The sign at the edge of the village said: Localhost Village. Population: 127.
If you work in software, you may smile at that name. Localhost is what a computer calls itself, and its address is 127.0.0.1. For everyone else, it is a small village where a local host welcomes you.
This village is a metaphor. The problems and solutions are real.
When I moved here, my first week was a mess. I wanted bread. Nobody told me the bakery opens at six in the morning. I wanted to pay my water bill. It turned out you pay it at the grocer, not at the village office. I needed a paper signed. Only the muhtar had the stamp, and he was out.
Everyone knew these things. Nobody had written them down. The village worked, but only in people’s heads.
Get Ercan Şahin’s stories in your inbox
Join Medium for free to get updates from this writer.
In software, this is a common problem. How the system works lives in the heads of a few senior people. When they are on holiday, work slows down. When they leave, the knowledge goes with them.
I have lived this in every company I have joined. There was always a system, but no how to use, mappings and docs. To understand the system, I first had to understand the developers. I went through all of this to build the system’s institutional memory: knowledge that stays, even when people leave.
Village problems, software solutions
A few weeks later, the muhtar drew the village on a big sheet of paper and hung it in the office. He did not draw the houses. He drew the places that matter, and the lines between them. The office in the middle. The grocer, with an arrow for money. The mill that serves five villages. The well. The bridge, with a note: “closed when the river is high.”
Nothing on the map was new. But a newcomer could understand the whole village in five minutes.
In software, this is called a system context diagram. It is the first of four levels in the C4 model, a popular way to draw software. It shows the whole system on one page: who uses it, and what it talks to.
The muhtar’s map follows three rules:
- One page. If it does not fit on one page, it is too detailed.
- Places and lines/roads. Show what exists, and who talks to whom.
- Location is marked. You can follow the way with your finger.
Your software has the same map. Some villagers can be users. The village office is where the system keeps their accounts. The grocer’s notebook is where it records the money. And the roads out of the village go to outside companies; integrations with a other providers.
Do not try to draw everything at once. Nobody reads a huge map. Start with the big picture and zoom in later. And keep it true: the muhtar updated his map when something changed, and someone in your team should do the same.
Villager Identification — Grocery Reconciliation — Mill-Tenant
This post is the signpost, the entrance of the village. From now, I can see three problems in this village.
The first is at the village office. The muhtar keeps one record for each villager, but one day two men came with the same name and he had to work out who is who.
The second is at the grocer. He writes every coin in his notebook. Still, at the end of the month, his notebook and his customers do not always agree.
The third is at the mill. One mill works for five villages. When they all come on the same day, someone has to wait, and the flour can get mixed.
If you work in software, you already know these problems by other names: identity, the ledger and multi-tenancy. We will walk to each one. When we find a new problem, we will add a new spot to the map.
That is enough for a first day. Try to draw the map of your own village this week. I will see you on the road.
