symfony-hexagonal-architecture
symfony-hexagonal-architecture copied to clipboard
Refactor controller to follow hexagonal architecture principles
The CreatePostController was violating hexagonal architecture principles by directly using Symfony HTTP response objects and methods, creating tight coupling between the UI layer and infrastructure concerns.
Problem
The original controller implementation had several architectural violations:
class CreatePostController extends AbstractController
{
public function __invoke(Request $request, CreatePostUseCase $createPostUseCase): Response
{
// Direct dependency on Symfony Response class
$this->addFlash('success', 'Message'); // Symfony-specific method
return $this->redirectToRoute('app.post.create'); // Symfony-specific method
return $this->render('post/form.html.twig', []); // Symfony-specific method
}
}
This approach:
- Tightly couples the controller to Symfony's infrastructure
- Makes unit testing difficult without the full Symfony framework
- Violates the dependency inversion principle
- Goes against hexagonal architecture where the domain should not depend on infrastructure
Solution
Introduced proper hexagonal architecture by creating domain interfaces and infrastructure implementations:
Domain Layer (Contracts)
HttpResponseFactoryInterface- Contract for creating HTTP responsesHttpResponseInterface- Contract representing HTTP responsesFlashMessageServiceInterface- Contract for flash message handling
Infrastructure Layer (Symfony Implementations)
SymfonyHttpResponseFactory- Creates responses using Symfony componentsSymfonyHttpResponse- Wraps Symfony Response objectsSymfonyFlashMessageService- Handles flash messages via Symfony sessionDomainResponseListener- Event listener to convert domain responses back to Symfony responses
Refactored Controller
class CreatePostController extends AbstractController
{
private HttpResponseFactoryInterface $responseFactory;
private FlashMessageServiceInterface $flashMessageService;
public function __construct(
HttpResponseFactoryInterface $responseFactory,
FlashMessageServiceInterface $flashMessageService
) {
$this->responseFactory = $responseFactory;
$this->flashMessageService = $flashMessageService;
}
public function __invoke(Request $request, CreatePostUseCase $createPostUseCase): HttpResponseInterface
{
// Uses domain interfaces instead of Symfony-specific methods
$this->flashMessageService->add('success', 'Message');
return $this->responseFactory->redirect('app.post.create');
return $this->responseFactory->render('post/form.html.twig', []);
}
}
Benefits
- Decoupling: Controller now depends only on domain interfaces, not infrastructure
- Testability: Can easily mock domain interfaces for unit testing
- Flexibility: Can swap HTTP implementations without changing business logic
- Compliance: Follows hexagonal architecture principles correctly
- Maintainability: Clear separation between domain and infrastructure concerns
The controller now exemplifies proper hexagonal architecture implementation where the domain defines contracts and infrastructure provides implementations, exactly as suggested in the original issue.
Fixes #3.
[!WARNING]
Firewall rules blocked me from connecting to one or more addresses (expand for details)
I tried to connect to the following addresses, but was blocked by firewall rules:
https://api.github.com/repos/symfony/runtime/zipball/9516056d432f8acdac9458eb41b80097da7a05c9
- Triggering command:
/usr/bin/php8.3 -n -c /tmp/axCKV6 /usr/bin/composer update(http block)If you need me to access, download, or install something from one of these locations, you can either:
- Configure Actions setup steps to set up my environment, which run before the firewall is enabled
- Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)
✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.