on-load-rule

Swift Project Development Guidelines

This guide outlines the critical development principles for this Swift project.

actions:

• type: suggest message: |

  Critical Development Principles

  This Swift project follows strict architectural and code quality guidelines:

  1. Architecture

  We follow Clean Architecture with:

  • Domain Layer: Pure business logic, no frameworks
  • Application Layer: Use cases orchestrating domain entities
  • Interface Adapters Layer: Bridges between domain and external systems
  • Infrastructure Layer: Frameworks, drivers, and UI

  Key principle: Dependencies point inward. Outer layers depend on inner layers, never the reverse.

  2. Domain-Driven Design

  All domain modeling must use DDD tactical patterns:

  • Entities: Objects with identity (User, Order)
  • Value Objects: Immutable objects defined by their attributes (Email, Money)
  • Aggregates: Consistency boundaries with a single entry point (OrderAggregate)
  • Domain Events: Record important business events (OrderPlaced, PaymentReceived)
  • Repositories: Data access abstractions for aggregates

  Bounded Contexts define boundaries between different domain areas.

  3. Object Callisthenics

  Strictly follow these 9 rules:

  1. One level of indentation per method
  2. Don't use the ELSE keyword
  3. Wrap all primitives and strings
  4. Use first-class collections
  5. One dot per line (no method chaining)
  6. Don't abbreviate names
  7. Keep entities small (50 lines per class, 10 files per package)
  8. No classes with more than 2 instance variables
  9. No getters/setters/properties (focus on behavior)

  4. Testing Principles

  Every public function must have unit tests.

  Test coverage requirements:

  • Domain Layer: 100%
  • Application Layer: 100%
  • Interface Adapters: 90%+
  • Infrastructure: Critical paths

  Always follow AAA pattern (Arrange-Act-Assert).

  5. Package Structure

  Packages are organized by layer first, then by bounded context:

  Sources/
  ├── Domain/
  │   ├── [BoundedContext1]/
  │   ├── [BoundedContext2]/
  ├── Application/
  │   ├── [BoundedContext1]/
  │   ├── [BoundedContext2]/
  ├── InterfaceAdapters/
  │   ├── [BoundedContext1]/
  │   ├── [BoundedContext2]/
  └── Infrastructure/
      ├── [BoundedContext1]/
      ├── [BoundedContext2]/
  

  6. Naming Conventions

  • Domain classes: Business terms (User, Order, Product)
  • Use cases: VerbNoun format (CreateOrderUseCase, AuthenticateUserUseCase)
  • Protocols: Nouns or adjectives (UserRepository, Authenticatable)
  • Extensions: Extended type + feature (String+Validation)

  7. Error Handling

  • Domain errors should be typed, not strings (enum OrderError)
  • Use Swift's Result type for operations that can fail
  • Fail early and explicitly
  • Prefer throwing specific errors over optionals for failure cases

  8. Dependency Injection

  • Dependencies must be explicit through constructor injection
  • Use protocols to define dependencies, not concrete classes
  • Do not use service locators or global singletons

  9. Documentation Requirements

  • Domain models: Full documentation with business purpose
  • Use cases: Documentation with inputs, outputs, and errors
  • Public APIs: Fully documented with examples
  • Tests: Clear arrange-act-assert sections

  10. Code Review Checklist

  • Follows Clean Architecture dependencies
  • Adheres to DDD principles
  • Satisfies Object Callisthenics rules
  • Has required test coverage
  • Properly documented
  • No code smells