OTAKU / The manifesto

Chapter 01 — Rigid core, flexible edges

The OTAKU Manifesto

OTAKU is an acronym, and every letter is a constraint. Forty rules make it measurable; one metric decides whether a method is too complex to exist.

The philosophy has a rigid core and flexible edges. The core — the five pillars and the thresholds that operationalize them — does not negotiate. The edges — language, framework, style, tooling — are free.

The five pillars are ordered on purpose. Discipline is first because nothing else survives without it. Contracts are last because they are the only thing the outside world is allowed to see.

O

Own your Discipline

Be strict with yourself.

Restriction is the only path to liberation. Complexity, size and naming are measured, not debated.

T

Tools for Composition

Compose like Unix.

Small parts with clear inputs and outputs. The application is a data pipe, and side effects stay at the edges.

A

Armor the Core

Protect the heart of the business.

Dependencies point inwards only. Entities and use cases never learn the name of a framework.

K

Keep Infrastructure Silent

Infrastructure is just a detail.

Persistence behaves like an in-memory collection. Failure is explicit; state is immutable by default.

U

Universal Language & Contracts

Speak the user’s language.

Ubiquitous language made explicit in design-first contracts. Primitives are wrapped; every public method has a contract.

The primary metric

Cyclomatic complexity — Thomas J. McCabe’s count of independent paths through a method — is the philosophy’s main instrument. A method with cyclomatic complexity above 5 is rejected, regardless of how readable it looks. Five paths are already five branches of reasoning a reader must hold at once.

Everything else in the discipline section is a way to keep that number low: one level of indentation, no ELSE, no switch/case, guard clauses, extraction. The metric is measurable in every language in this book, and every ecosystem has a tool that reports it.

The forty rules

Every rule has a measurable threshold. When in doubt, choose the more restrictive option.

40 rules · 7 groups · 5 pillars

OComplexity

  1. Cyclomatic complexity per method must not exceed 5.
  2. Only one level of indentation per method.
  3. Do not use the ELSE keyword (guard clauses or early returns).
  4. Never use switch/case (polymorphism, match expressions or strategy).
  5. Avoid magic numbers and strings (constants or enums).

OSize

  1. Maximum of 50 lines per class (code inside the class body only).
  2. Maximum of 20 lines per method (executable code only).
  3. Maximum of 10 classes per namespace or package.
  4. No class with more than two instance variables.
  5. Methods must have no more than two parameters.
  6. Constructors must have no more than two parameters.
  7. Interfaces must have no more than two methods.

ONaming

  1. Do not abbreviate; use full, descriptive names.
  2. Boolean methods start with is, has, can or should.
  3. Method names start with a verb.
  4. Constants are UPPER_SNAKE_CASE.
  5. Property and method names are camelCase.

TModularity

  1. First-class collections: wrap arrays in dedicated classes.
  2. One dot per line; avoid method chaining for readability.
  3. Static methods are forbidden except factories and pure functions.
  4. Commands and queries are separate: no side effects in value-returning methods.
  5. Functions are pure when possible: same input, same output, no side effects.
  6. No global state or singletons; inject dependencies explicitly.
  7. Prefer small, focused functions; extract when a method does more than one thing.

AProtection

  1. No getters, setters or public properties; use behaviour methods.
  2. Properties are private by default; protected only for framework inheritance.
  3. Classes are final by default; extension happens through interfaces.
  4. Inheritance is forbidden except framework base classes; prefer composition.
  5. Validate all input at the boundary: constructors and public methods.
  6. Fail fast: throw as soon as a precondition is violated.
  7. Never mutate input parameters; treat them as immutable.

KSide effects and failure

  1. Prefer immutability: readonly properties, return new instances.
  2. Methods returning collections return empty collections, never null.
  3. Methods that may fail return Result/Either or throw; never null.
  4. Explicit over implicit: no hidden dependencies, magic methods or implicit conversions.
  5. Never leak infrastructure details (SQL, HTTP, file paths) into the domain.

UContracts

  1. Wrap all primitives and strings in value objects.
  2. No generic types (mixed, array, object) except explicit serialization methods.
  3. Every public method is declared in an interface.
  4. Comments explain why, and belong in contracts, not implementations.

How the pillars enforce each other

Discipline makes composition possible: a 300-line class cannot be replaced. Composition makes the core defensible: a monolith cannot hide its dependencies. A protected core makes infrastructure genuinely optional. Contracts are the only reason any of it can be verified from outside.

Remove one pillar and the others become ceremony. Keep all five and the system becomes boring — in the way bridges are boring.