Software Design Mind Map
Algorithm & Systems VisualizationsEvery software design visualization on this site on one map. The branches are the main ideas. Each leaf is a page; the grey line under it is the one thing to remember about it. Click a branch to focus on it, click a page to open it.
1. How the map is organized
Ask what size of thing the idea shapes:
- A rule for any class? It is a principle: SOLID, or choosing composition over inheritance.
- A small reusable set of classes with a name? It is a design pattern. The layout of the whole app (where the domain sits, how the UI updates) is architecture.
- Git? How bytes are stored on disk is Git storage; how branches move and histories join is Git branches & merging.
2. The branches side by side
| Branch | Question it answers | Key idea |
|---|---|---|
| Principles | Will a change stay in one place? | depend on interfaces, small classes |
| Design patterns | Which known shape fits this problem? | an interface plus objects you swap or wrap |
| Architecture | Where do domain, UI and I/O live? | core logic knows nothing of the outside |
| Git storage | How does Git keep every version? | immutable objects named by their hash |
| Git branches & merging | How do two lines of work join? | branches are pointers; merge uses the base |
3. Five facts to remember
- Depend on interfaces, not concrete classes: then parts can be swapped and tested alone.
- Use inheritance only for a true is-a; composition lets behaviour mix freely.
- Decorator, Proxy and Adapter all wrap an object; they differ in intent: add behaviour, control access, change the interface.
- A Git commit points to one tree and its parent commits; every object is named by the hash of its content.
- A branch is only a pointer. Rebase makes new commits with new hashes, so do not rebase history others already have.
See all software design pages in the index, or the other mind maps.