Hexagonal Architecture in TAHO
TAHO embraces hexagonal architecture (also known as Ports and Adapters) to create components that are:- Testable: Business logic isolated from infrastructure
- Flexible: Swap implementations without changing core logic
- Maintainable: Clear separation of concerns
- Reusable: Adapters can be shared across components
Key Principle: Your business logic should not know or care whether it’s reading from PostgreSQL or MongoDB, serving HTTP or gRPC, or running on AWS or Azure.
Architecture Overview
Core Concepts
Ports
Ports define the interfaces between your domain logic and the outside world:- Input Ports: How the outside world interacts with your domain
- Output Ports: How your domain interacts with external systems
Adapters
Adapters implement the ports for specific technologies:- Primary Adapters: Drive the application (HTTP handlers, CLI, message consumers)
- Secondary Adapters: Are driven by the application (databases, APIs, file systems)
Domain Core
Domain Core contains pure business logic with no infrastructure dependenciesPractical Example: Order Service
Let’s build an order processing service using TAHO’s port & adapter pattern:1. Define the Domain Model
2. Define Ports
- Input Ports
- Output Ports
3. Implement Domain Logic
4. Create Adapters
- HTTP Adapter
- Database Adapter
- Message Queue Adapter
5. Wire Everything Together
TAHO-Specific Features
Dynamic Adapter Loading
TAHO allows adapters to be loaded dynamically at runtime:Adapter Composition
Combine multiple adapters for advanced scenarios:Hot-Swappable Adapters
Change adapters without restarting:Testing with Ports & Adapters
The architecture makes testing straightforward:- Unit Tests
- Integration Tests
Best Practices
Keep Ports Focused
Keep Ports Focused
- One port per concern (don’t mix repository and messaging)
- Use domain language in port definitions
- Avoid leaking infrastructure details into ports
- Keep port interfaces small and cohesive
Domain Purity
Domain Purity
- No infrastructure imports in domain code
- Use value objects for type safety
- Validate at domain boundaries
- Express business rules clearly
- Avoid anemic domain models
Adapter Guidelines
Adapter Guidelines
- Adapters should be thin wrappers
- Handle all infrastructure errors
- Map between domain and infrastructure types
- Don’t put business logic in adapters
- Make adapters replaceable
Testing Strategy
Testing Strategy
- Unit test domain logic with mocked ports
- Integration test adapters against real systems
- Use test doubles for external dependencies
- Test error scenarios thoroughly
- Verify adapter contracts