Architecture Packages

An architecture package is a complete blueprint for a software architecture style. Each package includes metadata, documentation, skills, and templates that ensure every generated solution follows consistent patterns.

What is an architecture package?

An architecture package encodes an architect's decisions into a reusable, executable format. It captures not just the folder structure, but the full set of patterns, conventions, and implementation details that make an architecture work in practice.

Each package contains:

• Metadata — Name, description, layers, and tech stack of the architecture
• Documentation — Markdown-based description of the architecture's patterns, conventions, and decision rationale — used by the AI as context when executing skills
• Skills — Step-by-step instructions for common tasks (create solution, add service, implement feature)
• Templates — Source code files with variable placeholders for consistent code generation
• Configuration — Customizable options like layer naming, endpoint styles, and ID strategies

Choosing the right architecture

The right architecture depends on your team size, deployment needs, and complexity requirements. Consider these questions:

• How many teams will work on the codebase? Independent teams benefit from stronger boundaries.
• How do you deploy? Single deployable vs. independently deployable services.
• How complex is the domain? Rich business logic benefits from domain-centric designs.
• What's your scale? Independent scaling requirements push toward service boundaries.

Built-in example packages

Golden Path ships with three .NET architecture packages that serve as both ready-to-use solutions and reference implementations for building your own packages.

Package	Best for	Deployment
Clean Architecture	Complex domain logic, single team	Single deployable
Modular Monolith	Module boundaries, shared database	Single deployable
Microservices	Independent teams, separate scaling	Multiple deployables

---

Clean Architecture

Domain-centric design with strict dependency rules. The domain layer has zero external dependencies — all infrastructure concerns point inward.

Key patterns: CQRS with MediatR, Repository pattern, Domain Events, Rich Domain Models

Skills included: create-solution, add-module, implement-feature, add-authentication, add-authorization

---

Modular Monolith

Independent modules within a single deployable. Each module owns its data and communicates with other modules through well-defined contracts — not direct database access.

Key patterns: Module isolation, Integration Events between modules, Outbox Pattern, per-module DbContext

Skills included: create-solution, add-module, implement-feature, add-authentication, add-authorization

---

Microservices

Independently deployable services, each with its own database and communication via asynchronous events. Built for teams that need independent release cycles and isolated scaling.

Key patterns: Event-Driven Architecture, Outbox Pattern, Eventual Consistency, per-service database, API Gateway

Skills included: create-solution, add-service, implement-feature, add-authentication, add-authorization, add-aspire, add-otel

---

Creating your own packages

You can create architecture packages for any tech stack and architecture style. Point plan_architecture at an existing reference repo, and the AI analyzes the codebase, designs the skill set, extracts templates, and registers the complete package — ready to use.

---

Configurable options

The built-in .NET packages support these configurable options: