Skip to content

README

Introduction to Acquiring's Architecture Decisions

The documents in this folder cover how acquiring has been designed and how it works. It's intended to aid in understanding the code, and hopefully to enable people to modify it.

Many of this design decisions have been made as the project has grown. Personally, that's how most of the programming decisions I've made have happened. For that reason, I decided to document the architecture decisions I've been making along the way.

People without dirty hands are wrong.

Decisions, therefore, are short notes on guiding principles that informed both the high level breakdown and the low level implementation details of this project. Everything is a draft, because it helps to get it done.

This idea is not new. It is heavily inspired by a post by Michael Nygard, who is behind the concept of Architectural Decision Records, or ADRs.

The problem with ADRs is that they enforce a structure that is too rigid and not very stimulating to read.

Instead, a decision can have any structure, but it has to conform to five important rules:

  1. It must be concise
  2. It must be complete
  3. It must be easy to understand
  4. It must be pleasant to read
  5. Once it's committed, it must never be edited.

ADR 0001 is left the way ADRs are meant to be written. The rest, though, conform to these rules.