tzurot-architecture

Microservice boundaries separate distinct responsibilities into independent services. Tzurot v3 architecture delineates three core services: bot-client handles Discord interactions, api-gateway manages HTTP requests and job queues, and ai-worker processes AI logic and memory. Clear boundaries prevent circular dependencies and enforce single-responsibility ownership.

Enforce strict single-responsibility boundaries and use shared types in a common-types module to prevent duplication across services. Constructor injection makes dependencies explicit. Each service owns specific code modules mapped to its responsibility, avoiding back-references and keeping the dependency graph acyclic.

Place shared types, utilities, and shared services in a common-types module accessible to all microservices. This prevents code duplication, ensures consistency across the monorepo, and maintains clean service boundaries without services depending directly on each other's implementation.

Trace the feature's data flow through your service architecture. In Tzurot v3, Discord interactions belong to bot-client, API requests to api-gateway, and AI processing to ai-worker. Assign ownership based on the primary responsibility; use inter-service communication patterns for cross-cutting concerns.

Avoid over-engineering, excessive abstraction layers, and complex dependency injection containers that obscure service responsibilities. Keep classes simple and focused. Use explicit constructor injection instead of service locators, and maintain clean separation between services to prevent the tight coupling that plagued earlier architecture versions.

Yes. A monorepo can enforce microservices design through strict code ownership, shared type modules, and clear service boundaries without separate deployments. Tzurot v3 uses this approach: bot-client, api-gateway, and ai-worker maintain distinct responsibilities within a single codebase through constructor injection and anti-circular-dependency rules.