4. Layered Architecture

Appcraft scaffolds projects around a Clean Architecture layout: each layer has one responsibility and depends only on the layers “beneath” it, never the other way around. This keeps business rules independent of frameworks, databases, and delivery mechanisms, so any of those can change without rippling through the rest of the codebase.

The layers, from the outside in:

1. Runner: the entry points of the generated application. A runner receives command-line input and calls into the Presentation layer.

2. Presentation: input validation, output formatting, and error translation for a specific delivery mechanism (CLI today, or a web framework like Flask). It depends on the Application layer.

3. Application: orchestrates business logic — use cases, repositories, ports, mappers, providers, schemas. It depends only on the Domain layer.

4. Domain: the core business entities, value objects, and abstract contracts (interfaces, filters). It has no framework or infrastructure dependencies at all.

5. Infrastructure: concrete implementations — database adapters, third-party API clients, the framework’s own runtime utilities. It implements the contracts the Domain and Application layers define.

Dependencies only ever point inward (Runner → Presentation → Application → Domain), with Infrastructure implementing contracts defined by the layers it supports rather than being depended on directly by Domain or Application business logic.

Architecture Layers

• 4.1. Runner Layer
  • 4.1.1. What to Do in Runners
  • 4.1.2. What to Avoid in Runners
  • 4.1.3. Types of runners
  • 4.1.4. Example of a Runner
  • 4.1.5. Running Applications
  • 4.1.6. Running Tool Runners
  • 4.1.7. Executing a Specific Runner
• 4.2. Presentation Layer
  • 4.2.1. What belongs here
  • 4.2.2. What to avoid here
  • 4.2.3. Naming convention: <Domain>CLIPresentation
  • 4.2.4. Example: a CLI Presentation
• 4.3. Application Layer
  • 4.3.1. What belongs here
  • 4.3.2. What to avoid here
  • 4.3.3. Naming conventions
  • 4.3.4. Example: a Port
  • 4.3.5. Example: a Repository
  • 4.3.6. Example: a Mapper and Schema
  • 4.3.7. Example: a Use Case
  • 4.3.8. Introspection use cases
• 4.4. Domain Layer
  • 4.4.1. What belongs here
  • 4.4.2. What to avoid here
  • 4.4.3. Naming convention: a pure contract, not I + name
  • 4.4.4. Example: a domain model
  • 4.4.5. Example: a filter
• 4.5. Infrastructure Layer
  • 4.5.1. What belongs here
  • 4.5.2. What to avoid here
  • 4.5.3. Naming convention: Adapter
  • 4.5.4. Example: the default database Adapter
  • 4.5.5. Providers

Application flow

• 4.6. Application Flow
  • 4.6.1. Request Flow
  • 4.6.2. Response Flow