backend-engineer

Implement bounded-context APIs within a Modular Monolith using Hono routing.

14|1|Updated Oct 23, 2025

Search Tags:#typescript #backend #hono #bounded-context #modular-monolith

Ready to run

npx skills add https://github.com/marcioaltoe/claude-craftkit --skill backend-engineer-marcioaltoe

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: backend-engineer
Source: https://github.com/marcioaltoe/claude-craftkit/tree/main/plugins/architecture-design/skills/backend-engineer
Command: npx skills add https://github.com/marcioaltoe/claude-craftkit --skill backend-engineer-marcioaltoe

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides guidance on building backend architectures with bounded contexts, modular monoliths, and Hono-based HTTP layers.

Core Features & Use Cases

Context Isolation: Define vertical slices for each domain.
Hono Route Design: Create backend endpoints and service layers.
DI & Testing: DI patterns and testable architecture.

Quick Start

Outline a minimal context with an API route and associated domain service.

Frequently Asked Questions about backend-engineer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I structure a backend with bounded contexts in a modular monolith?▼

Bounded contexts in modular monoliths organize your backend into vertical slices, each with independent domain, application, and infrastructure layers. Use a folder structure that separates contexts by domain (auth, tax, BI, production), define APIs per context using Hono routing, and communicate between contexts via services rather than direct coupling to maintain isolation and testability.

Can I build TypeScript backend APIs with Hono and PostgreSQL using a modular structure?▼

Yes. Hono provides HTTP routing for backend endpoints, PostgreSQL with Drizzle handles data persistence, and a modular monolith structure lets you organize these across bounded contexts. This stack supports independent domain layers, repository patterns, use-case implementation, and dependency injection for testable, maintainable code.

What's the best way to separate concerns in a backend using domain-driven design patterns?▼

Apply bounded contexts to isolate domains vertically, then split each context into domain, application, and infrastructure layers. Domain handles business logic, application coordinates use cases and DI wiring, infrastructure manages persistence and external communication. This separation prevents coupling and makes testing and maintenance straightforward across auth, tax, BI, and production domains.

How do I implement dependency injection and testing in a modular monolith backend?▼

Use a DI container to wire services within each bounded context, keeping dependencies scoped to their domain layer. Structure repositories and use cases to accept injected dependencies, then test in isolation using Vitest. This pattern ensures each context remains independently testable and reduces tight coupling between domains.

Does this approach work for communication between different backend domains like auth and tax?▼

Yes. Use service-based communication between bounded contexts—auth, tax, BI, and production domains interact through defined service boundaries rather than shared databases or direct layer access. This maintains context isolation, enables independent scaling, and follows the duplication-over-coupling principle.