Choosing Our Layers

Categories of layers

We recommend the following software layers:

• Data structures

• A functional core

• Tests

• Boundaries

• Lifecycle

• Workers

Not every project will have all of these layers, but some will. It’s our job as the author of a codebase to decide which layers are worth the price and which ones to eliminate. It’s a lot to remember, so use this sentence as a mnemonic:

Do fun things with big, loud worker bees.

The first letters of the essential words in the sentence match the first letters in our layers:

• Data (do)

• Functional core (fun)

• Tests (things with)

• Boundaries (big)

• Lifecycles (loud)

• Workers (worker bees)

We can see how they all fit together in the following figure:

Understanding layers

In this course, we’ll explore each layer in detail. We’ll call each unit of software we build that honors these concepts a component.

To help you understand what each of these layers do, we’re going to build two components. The first will be a trivial counter. You may know how counters work, but making this component will help us internalize the design framework we’ve established and what each of the layers means.

The next component, a project called Mastery, will be much more complex and will take up the rest of the course. It will be a quiz, but not a typical one. This quiz will tailor itself as the user answers questions. Its purpose will be to help us learn to use the design framework in context to build a project with real complexity.

---