Documentation | Architecture and Modules
How ApisKit is built, what it solves, what remains specific to your project, and how to work with the codebase.
Start with what you need to know
If you're evaluating ApisKit
You can check which decisions are part of the template and which responsibilities will still depend on your product, your infrastructure, and your business.
If you already have a copy
The documentation becomes the project's reference. It is designed to accompany the code: it explains the decisions you need to understand in order to work on top of the base without first having to reconstruct how it is organized.
If you want to reuse a piece
ApisKit is not designed as an indivisible block. Some parts are designed to be moved into other projects while keeping their dependencies and the contracts they require from the receiving system explicit.
Documentation that is part of the product
The published pages are part of ApisKit's quality gate.
The system automatically checks conditions that code analysis alone cannot detect, such as incomplete documentation, missing languages, duplicate URLs, pages outside the navigation, or images missing the required information.
If a check cannot be executed, it is not presented as successful.
It doesn't just document what to do
When a decision affects the behavior of the system, the documentation also explains why it exists, what it depends on, and what may stop working if it is changed.
| When reviewing a decision | You can identify |
|---|---|
| Why it exists | The problem or responsibility it is solving. |
| What it depends on | The parts of the system, services, or contracts involved. |
| What it protects | The behavior that decision is intended to preserve. |
| What changes if you replace it | What you will need to preserve, adapt, or implement again. |
The intention is not for you to keep every ApisKit decision forever. It is to make sure that, when you replace one, you know what problem it was solving and which responsibility becomes yours.
