skills.rest
kreek
kreekCOMMUNITY
Explore all skills by this author →
GitHub

architecture

Guides module boundary, layering, and coupling decisions for software system organization.

1|Updated Apr 24, 2026
Search Tags:#architecture#system design#ddd#code organization#module boundaries#coupling#layering
One-click install
npx skills add https://github.com/kreek/consult --skill architecture-kreek
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architecture
Source: https://github.com/kreek/consult/tree/main/plugin/skills/architecture
Command: npx skills add https://github.com/kreek/consult --skill architecture-kreek

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Choosing how to organize code into modules, layers, and boundaries is a high-stakes decision that is expensive to reverse, yet teams often default to horizontal controller/service/repository layering or premature DDD patterns that scatter one behavior across many files. ## Core Features & Use Cases - Boundary Decision Rules: Organizes code by what changes together, requiring layers only for real process, deploy, trust, persistence, or transport boundaries. - Contract-First Boundaries: Ensures module boundaries expose contracts rather than internal steps, with callers depending only on the public surface. - DDD Discipline: Applies aggregates, repositories, and bounded contexts only when they protect a named invariant, workflow, or ambiguous term. - Use Case: When starting a new service, use it to decide between feature-oriented organization and horizontal layers, then record the reasoning in an ADR before any files are moved. ## Quick Start Use the architecture skill to decide the module boundaries and layering for my new payments service before I scaffold the project.

Frequently Asked Questions about architecture

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

FAQPage Schema
How do I choose between feature-based and layered architecture?▼

Group code by capability first so behavior, data shapes, and tests change together. Add horizontal layers only where a real boundary exists, such as process, deploy, trust, persistence, or transport separation.

When should I use DDD patterns like aggregates and repositories?▼

Apply DDD tactical patterns only when they protect a named invariant, workflow, or a term that means different things in different contexts. Adding them purely for structure creates indirection without benefit.

When should I not use this architecture guidance?▼

Skip it for data shape and invariant decisions (use domain-modeling), HTTP contract details (use api), physical schema (use database), or behavior-preserving code moves (use refactoring). Private file moves need no boundary decision.

How do I document architecture decisions for future readers?▼

Record decisions that cannot be recovered from the code, such as why a boundary exists or what alternatives were rejected, in an ADR, comment, or commit message.

What are signs of bad layering in a codebase?▼

A layer is harmful when one behavior is scattered across many files for no technical reason. Layers are justified only by an independent change axis like process, deploy, trust, persistence, transport, or proven duplication.

Related Skills

Explore More Software Engineering Skills→
gustavofsantosgustavofsantos

bounded-contexts

Define minimal contracts between modules to enforce clear boundaries.

Community
Intermediate
KotlinKotlin
14

kotlin-idiomatic-refactorer-spring-aware

Refactor Kotlin code idiomatically while preserving Spring, Jackson, and JPA contracts.

Official
Advanced
KotlinKotlin
14

domain-decomposition-api-design-advisor

Derive domain boundaries and API contracts for Kotlin + Spring systems.

Official
Advanced
jayteealaojayteealao

framework-conventions-guide

Enforce native conventions for Django, Laravel, Next.js, and Rails codebases.

Community
Basic