Architectural Decisions in EAF
This document captures key architectural decisions made for the ACCI EAF framework, providing context and rationale for major design choices.
🎯 Decision Overview​
Each architectural decision record (ADR) follows a structured format documenting the context, decision, and consequences.
📋 Decision Records​
ADR-001: Hexagonal Architecture Pattern​
Status: Accepted
Context: Need for clean separation of business logic from infrastructure concerns
Decision: Adopt hexagonal architecture with ports and adapters
Consequences: Improved testability and maintainability
ADR-002: Event-Driven Architecture​
Status: Accepted
Context: Requirement for loose coupling and scalability
Decision: Use NATS for event messaging between services
Consequences: Enhanced scalability but increased complexity
ADR-003: PostgreSQL as Event Store​
Status: Accepted
Context: Need for ACID compliance in event sourcing
Decision: Use PostgreSQL for event storage instead of specialized stores
Consequences: Simplified operations but potentially limited event store features
ADR-004: Spring Boot Framework​
Status: Accepted
Context: Need for enterprise-grade framework with ecosystem
Decision: Standardize on Spring Boot for all services
Consequences: Rich ecosystem and tooling but framework coupling
ADR-005: Domain-Driven Design Patterns​
Status: Accepted
Context: Complex business domains requiring clear modeling
Decision: Enforce DDD tactical patterns in all services
Consequences: Better domain understanding but steeper learning curve
🔄 Decision Process​
All architectural decisions follow a structured review process with stakeholder input and technical validation.
Architectural decisions provide transparency and context for EAF design choices.