Patterns

Engineering Patterns

Index of all patterns available in the Ontopix Engineering Handbook.

Production

For understanding the difference between Principles and Patterns, see the main README.


Organizational Patterns (Mandatory)

PatternProblem SolvedStatus
Repository StructureInconsistent file organization✅ Required
AI Agent EntrypointAgents don't know where to start✅ Required
Taskfile ContractInconsistent operational interfaces✅ Required
Infrastructure LayoutWhere to put Terraform/IaC✅ Required*
AWS Resource TaggingConsistent AWS resource tagging✅ Required*
Sandbox EnvironmentsSafe local development✅ Required*
Git ConventionsInconsistent git workflows✅ Required
GitHub ActionsCI/CD setup and patterns✅ Required
CodeArtifact + GitHub ActionsSecure package management from CI/CD✅ Recommended*
ECR + GitHub ActionsContainer image build and push from CI/CD✅ Recommended*

*Required if applicable: Infrastructure Layout (for repos with infrastructure), AWS Tagging (for repos provisioning AWS resources), Sandbox (for application repos), CodeArtifact (for repos publishing/consuming private packages), ECR (for repos deploying container images)


PatternProblem SolvedStatus
Python Module NamingPublic vs internal API boundaries✅ Active
Lambda DeployStandard Lambda code deployment from CI/CD✅ Active
AuthenticationUser identity verification🚧 Coming soon
CachingPerformance optimization🚧 Coming soon
Rate LimitingAPI protection🚧 Coming soon
Error HandlingConsistent error responses🚧 Coming soon

Pattern Template

When creating a new pattern, follow this structure:

# Pattern: [Name]

## Problem
[What problem does this solve?]

## Context
[When should you use this? When should you NOT?]

## Solution
[Detailed explanation of the pattern]

## Structure
[Code examples, file layouts, diagrams]

## Implementation
[Step-by-step guide]

## Applies Principles
[Which core principles does this embody?]

## Consequences
[Trade-offs, benefits, drawbacks]

## Examples
[Real-world usage from Ontopix repositories]

## Variations
[Different contexts or approaches]

## Related Patterns
[Links to complementary patterns]

## References
[ADRs, external resources]

Contributing Patterns

When to Create a Pattern

Create a pattern when you've solved the same problem 3+ times across different projects.

Good candidates:

  • ✅ Recurring problems with proven solutions
  • ✅ Common mistakes that need guidance
  • ✅ Complex implementations that benefit from templates
  • ✅ Solutions that apply across multiple projects

Not good candidates:

  • ❌ One-off solutions
  • ❌ Highly project-specific implementations
  • ❌ Unproven or experimental approaches
  • ❌ Simple problems with obvious solutions

Contribution Process

  1. Write the pattern - Follow the structure above
  2. Provide examples - Real code from Ontopix projects, not pseudo-code
  3. Document trade-offs - Be honest about limitations
  4. Link to principles - Show which principles this embodies
  5. Create PR - Get review from engineering leadership
  6. Update this index - Add your pattern to the appropriate section

Pattern Evolution

Patterns are living documents that evolve:

Versioning

When a pattern needs significant changes:

  • Keep old version for reference
  • Create new version with suffix: pattern-name-v2.md
  • Link between versions
  • Deprecate old version with migration guide

Deprecation

  1. Mark pattern as deprecated in this index
  2. Add deprecation notice to pattern file
  3. Provide migration path to new pattern
  4. Set sunset date (typically 6 months)
  5. Remove after sunset date

Related: Principles | Decisions | Templates