skills.rest
latitude-dev
latitude-devOFFICIAL
Explore all skills by this author →
Website𝕏@trylatitudeGitHub

architecture-boundaries

Define and enforce architecture boundaries across multi-layer applications.

4.6k|378|Updated Jun 28, 2024
Search Tags:#architecture#multi-tenant#ddd#guidelines#boundaries#layering#ports-adapters
One-click install
npx skills add https://github.com/latitude-dev/latitude-llm --skill architecture-boundaries
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architecture-boundaries
Source: https://github.com/latitude-dev/latitude-llm/tree/main/.agents/skills/architecture-boundaries
Command: npx skills add https://github.com/latitude-dev/latitude-llm --skill architecture-boundaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Layering and boundaries, web vs public API, app layout (clients, routes, logging), ports/adapters, runtime-portable domain/shared/utils code, multi-tenancy, DDD layout, or anti-patterns.

Core Features & Use Cases

  • App boundaries: Apps only handle input validation, authentication/authorization, organization access enforcement, and routing to domain use-cases. No business logic in handlers, controllers, or jobs.
  • Application layout: Clients initialize integrations in apps/*/clients.ts and import from boundaries; Routes use registerRoutes() to keep the HTTP surface modular; Logging uses createLogger() from @repo/observability; Tracing rules require withTracing in Effect pipelines; Configuration reads env via parseEnv/parseEnvOptional.
  • Web vs public API: apps/api is the stable public surface; apps/web should not proxy through apps/api for internal features; keep web-private server functions modular; share domain rules; ensure machine-facing surfaces exist.
  • Cross-cutting constraints: Public request/response schemas should remain boundary-specific; reuse domain schemas; prefer Web standards; avoid Node-only dependencies at runtime.
  • Domain layer: Domain entities are Zod-first; canonical schemas and inference lives in packages/domain/*/src/entities; domain errors, constants, and helpers live in their respective domain paths.
  • Infrastructure: Platform adapters; how to structure Effect-based clients; bootstrap, error handling via tagged errors; env parsing; layering and health checks.
  • Shared utilities: Place generic helpers in @repo/utils; ensure web-standards-first.
  • Multi-tenancy: Every request is organization-scoped; membership checks at boundaries; telemetry paths include organizationId.
  • Domain design: Bounded contexts, single-responsibility domains, in-memory adapters for tests.
  • Anti-patterns to reject: e.g., cross-domain logic without ownership, new provider integrations without contracts, unnecessary env vars, etc.

Quick Start

Consult this Skill to structure and enforce boundaries across your codebase, from apps/* to domain layers, implementing proper ports/adapters and separation of concerns.

Frequently Asked Questions about architecture-boundaries

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

FAQPage Schema
How do I separate web API from internal app logic in a multi-tenant architecture?▼

To separate web API from internal app logic, keep apps/api as the stable public surface while ensuring apps/web does not proxy through it for private features. Apps should only handle input validation, authentication, organization access enforcement, and routing, leaving no business logic in handlers or controllers.

What is the ports and adapters pattern for structuring domain boundaries?▼

The ports and adapters pattern structures domain boundaries by using platform adapters for infrastructure and keeping domain entities, Zod schemas, and errors isolated in packages/domain. This runtime-portable domain code avoids Node-only dependencies, ensuring web-standards-first reusability across different environments.

How do I enforce organization-scoped boundaries for multi-tenancy?▼

To enforce multi-tenancy boundaries, ensure every request is organization-scoped by performing membership checks at the application boundaries. Telemetry paths must include organizationId, and cross-cutting constraints should reuse domain schemas while keeping public request and response schemas boundary-specific.

Can I put business logic in route handlers if I use Effect pipelines for tracing?▼

No, route handlers must not contain business logic even when using Effect pipelines with withTracing. Handlers should exclusively manage input validation, authorization, and routing to domain use-cases, while logging uses createLogger and configuration reads environment variables via parseEnv or parseEnvOptional.

What are common anti-patterns when defining DDD bounded contexts?▼

Common anti-patterns to reject include implementing cross-domain logic without clear ownership, adding new provider integrations without establishing contracts, and introducing unnecessary environment variables. Proper DDD layout requires single-responsibility domains and in-memory adapters for testing bounded contexts.

When should I use @repo/utils versus domain-specific packages?▼

Use @repo/utils for generic, web-standards-first helpers that apply cross-cuttingly across the codebase. Domain-specific entities, canonical Zod schemas, inference, constants, and domain errors must live in their respective packages/domain/*/src/entities paths to maintain strict bounded context ownership.

Related Skills

Explore More Software Engineering Skills→
spencerbeggsspencerbeggs
2

effect-v4-observability

Instrument Effect v4 public boundaries with named spans and structured logging.

Community
Advanced
egorfedorovegorfedorov
39

ai-game-developer

Implement AI gameplay features behind adapters with runtime contracts and fallback strategies.

Community
Advanced
PaulJPhilpPaulJPhilp
785

effect-patterns-domain-modeling

Model Effect-TS domains with branded types, tagged errors, and Schema validation.

Community
Intermediate
chetan2921chetan2921

flutter-architecting-apps

Define layered architecture guidelines for structuring Flutter applications.

Community
Advanced