Architecture overview
Balyze is designed as a backend-first SaaS, with a strong emphasis on domain clarity, long-term maintainability, and controlled technical complexity.
At its current ALPHA stage, the architecture focuses on building a solid foundation rather than optimizing for scale or performance prematurely.
Architectural goals
The architecture of Balyze aims to:
- make domain rules explicit and enforceable
- clearly separate responsibilities between layers
- minimize technical debt from the earliest stages
- allow progressive extension without large refactors
The system is intentionally simple, but not simplistic.
High-level structure
Balyze follows a classical MVC approach, extended with explicit domain-oriented layers:
-
Models
Represent persisted domain entities and their relationships. -
Services
Encapsulate business logic and domain rules.
All non-trivial actions are implemented at this level. -
Policies / Gates
Handle authorization and ownership rules, independently from business logic. -
Enums
Represent finite domain states and transitions (e.g. application lifecycle).
Controllers remain thin and primarily orchestrate requests by delegating to services.
Domain-first approach
Domain rules are defined before implementation details.
Examples include:
- application lifecycle constraints
- editability rules after submission
- ownership and access boundaries
These rules are documented explicitly and enforced consistently at the service layer.
Separation of concerns
Each layer has a single responsibility:
- Controllers handle HTTP concerns
- Services handle business decisions
- Models represent state, not behavior orchestration
- Policies handle authorization, not domain validity
This separation reduces coupling and makes future changes more predictable.
What is intentionally out of scope
At the ALPHA stage, the following concerns are intentionally deferred:
- public API design
- frontend architecture
- advanced analytics
- performance optimization beyond reasonable defaults
These aspects will be addressed progressively once the core domain is validated.
Evolution and stability
The architecture is expected to evolve, but core principles are intended to remain stable.
Structural changes should be driven by:
- validated domain needs
- concrete limitations encountered
- explicit architectural decisions
Premature abstraction is avoided by design.