Skip to main content

Development Principles

The following principles drive architecture and design decisions in Axinom Mosaic.

Solve the common path first

Mosaic should make frequent tasks fast and predictable, because most teams spend most of their time on repeatable workflows. When defaults work well, teams can deliver features without building infrastructure from scratch. In practice, Mosaic ships opinionated building blocks for standard service setup, API patterns, and operational concerns so teams can focus on domain behavior.

Use familiar, proven technology choices

Developer productivity increases when the stack uses tools and patterns teams already understand. Familiar choices also reduce onboarding time and lower long-term maintenance risk. In Mosaic, this shows up as mainstream protocols, common backend and frontend conventions, and integrations that align with widely used ecosystem practices.

Make customization accessible

Customization should not be limited to platform specialists, because product requirements always diverge over time. Teams need to adapt quickly without waiting on deep framework internals knowledge. Mosaic exposes extension points, configurable templates, and clear contracts so any capable engineer can tailor behavior safely.

API-first by design

Every capability should be available programmatically, not only through the UI. This enables automation, scripting, CI/CD integration, and custom tooling around the platform. In Mosaic, UI actions map to underlying APIs so the same operations can be repeated by services, scripts, or external systems.

Keep the schema as a source of truth

A database schema captures the business model and should drive consistency across the stack. Treating schema definitions as authoritative reduces drift between storage and APIs, and UI behavior. Mosaic uses schema-driven patterns to align persistence, contract generation, and runtime validation.

Generate what should not be handwritten

Repeated boilerplate is expensive to maintain and easy to implement inconsistently. Code generation improves speed while preserving uniform structure and conventions across services. In Mosaic, scaffolding and generated artifacts provide reliable starting points for APIs, models, and integration surfaces.

Prefer strong typing

Types move many failures from runtime to development time, where they are cheaper to detect and fix. Strong typing also improves IDE support, refactoring safety, and shared understanding between teams. Mosaic emphasizes typed contracts and models across service boundaries to reduce integration defects.

Provide helper libraries for common concerns

Cross-cutting tasks like messaging, auth context handling, and error processing should be standardized instead of reimplemented per service. Shared helpers reduce duplicate logic and enforce consistent platform behavior. Mosaic includes reusable libraries for common tasks so teams can build domain logic instead of plumbing.

Was this page helpful?