Skip to content

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.