The OTAKU Manifesto
OTAKU reflects a technical obsession with mastery, discipline and structural purity. It is not a style guide — it is the set of constraints that decides whether a piece of code is allowed to exist.
Quality is not an accident, it is the result of intentional restriction. The nine rules of Object Calisthenics are mandatory: one level of indentation per method, no else, wrap every primitive, first class collections, one dot per line, no abbreviations, small entities, at most two instance variables, no getters or setters.
Write code that never needs “fixing” because it was built under absolute constraint.
Like Unix tools, each component does one thing well. Architecture is a set of small, replaceable parts connected by clear inputs and outputs. The application flow is a data pipe: input enters through adapters, traverses the core, and exits.
Treat your application flow as a data pipe, keeping logic isolated from side effects.
Business logic is the most valuable asset and must be protected from external change. Dependencies point inwards only. The heart — entities and use cases — never knows about frameworks, databases or external APIs.
The core must never know about frameworks, databases or external APIs.
Databases, mailers and brokers are secondary details. Persistence is treated as an in-memory collection through the Repository pattern, and entities are plain objects that know nothing about how they are stored.
Your entities are POPOs — completely ignorant of how they are saved or transmitted.
Ubiquitous Language bridges business and code, and Design-First Contracts make it explicit. The OpenAPI document is the immutable technical promise that allows systems to communicate.
If the code does not read like the business expert speaks, or if the contract is bypassed, the system is broken.
Repository taxonomy
Modularity is enforced at the source. Every repository must fit exactly one of these archetypes — there is no fourth option and no hybrid.
The smallest possible unit of granularity. If a component can be broken down further, it is not an atom. The structure is flat: a single level of directory inside src/, fulfilling one specific contract.
Examples: common-contract, http-value-object,http-client.
Connection points. They contain no logic; they orchestrate the union of atoms through composer.json dependencies, so that one install brings ten atoms at once.
Examples: common, http,data-transfer-object.
The living system. Not a library, but the implementation of the business heart, following Clean Architecture and DDD. It stays lean: anything generic is pushed down into atoms.
Examples: ensemble, koenma-id,grogu-gateway.