backend-architect

Hexagonal architecture isolates your domain logic in a core bounded context, then wraps it with ports (interfaces) and adapters (implementations) for external dependencies. This separates business rules from infrastructure, making systems testable and maintainable. Define domain boundaries first, then map ports for databases, APIs, and external services.

SOLID is five design principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion—that reduce complexity and coupling in backend systems. Applying them prevents code smells, improves testability, and makes refactoring safer by keeping each class or module focused on one reason to change.

Examine code for violations of SOLID, unclear domain boundaries, tight coupling between layers, and missing abstractions. Check that tests align with responsibilities, dependencies flow inward toward the domain, and business logic stays separate from infrastructure. Flag code smells like duplicate domain logic or hard-to-test functions.

Refactor when you detect code smells—tight coupling, scattered domain logic, poor testability, or unclear boundaries between features. Also refactor proactively when adding features becomes slow due to tangled dependencies, or when multiple services share duplicated business logic that should be a bounded context.

A bounded context is a logical boundary around a cohesive set of business rules and domain models. Identify contexts by grouping related entities and use cases, then define explicit interfaces (ports) where contexts communicate. This prevents domain logic from leaking across services and makes teams autonomous.

Write unit tests that verify domain logic in isolation, integration tests that check adapters and external dependencies separately, and avoid circular dependencies between test layers. Enforce the dependency graph: tests should mock or stub anything outside the core domain, ensuring Single Responsibility and testability.