Hexagonal architecture ita

Symfony e l'  
Architettura Esagonale

Software Developer, father, geek, PHP and
Node.js expert. Open-source enthusiast,
active contributor on GitHub and
StackOverflow.
Who am I?
Alessandro Minoccheri
Software developer @Flowing
@minompi
@AlessandroMinoccheri

Come viene creato di solito un progetto Symfony?
• Installazione del Symfony skeleton project
• Rimozione del codice demo
• Autogenerazione delle entitá
• Autogenerazione dei controller
• Pronti a sviluppare l’applicazione

Quanti punti nel codice dobbiamo
modificare per sostituire quel
servizio?
◆

42 differenti posti in tutta la code-
base.
◆

class PaymentController
{
public function payAction(Request $request, YourBankGateway $gateway)
{
$gateway->pay($request->get('amount'), false, false, 0, 'EUR');
}
}

class Payment
{
public function pay(Request $request)
{
$gateway = new YourBankGateway();
$gateway->pay($request->get('amount'), false, false, 0);
}
}

class User
{
public function pay(Request $request)
{
$gateway->pay($request->get('amount'));
}
}

Come mai esiste questa
situazione?
◆

I problemi nell’essere guidati dal framework
• Impossibilitá di aggiornare il framework e i vendors.
• Costi di manutenzione.
• Sviluppatori non motivati per I problemi del vecchio stack citato nel
punto 1.
• Applicazione non manutenibile perché c’é un forte accoppiamento.
• Molto debito tecnico.
• Impossibilitá di cambiare le implementazioni facilmente.

Quindi cosa é realmente
importante nel software?
◆

Ciò che apporta davvero valore nel
software è la soluzione al
problema specifico nel dominio
◆

Un pó di storia dell’Architettura
Esagonale
◆

L'architettura esagonale divide un sistema
in diversi componenti intercambiabili NON
accoppiati, come il core dell'applicazione,
il database, l'interfaccia utente, i test e le
interfacce con altri sistemi.
◆

E’ una sovra ingegnerizzazione?
◆

Codice Accoppiato
namespace AppService;
use SymfonyComponentHttpFoundationRequest;
class Payment
{
public function doPayment(Request $request)
{
$gateway->pay($request->get('amount'), false, false, 0);
}
}

Codice disaccoppiato
interface GatewayProvider
{
public function pay(Money $amount): void;
}

use AppValueObjectMoney;
class YourBankGateway implements GatewayProvider {
public function pay(Money $amount): void
{
//do stuff..
}
}

class Payment
{
/**
* @var GatewayProvider
*/
private GatewayProvider $gatewayProvider;
public function __construct(GatewayProvider $gatewayProvider)
{
$this->gatewayProvider = $gatewayProvider;
}
public function doPayment(Money $amount)
{
$this->gatewayProvider->pay($amount);
}
}

Perchè è così importante
disaccoppiare il codice?
◆

Applicazione mantenibile
• Le modifiche in una parte di un'applicazione dovrebbero interessare
il minor numero possibile di altri punti
• L'aggiunta di funzionalità non dovrebbe richiedere di toccare
nessuna parte della base di codice
• L'aggiunta di nuovi modi per interagire con l'applicazione dovrebbe
richiedere il minor numero di modifiche possibile
• Il debug dovrebbe richiedere il minor numero di workaround
• I test dovrebbero essere relativamente facili

Single responsibility é anche per l'
architettura: 
ciò che cambia per lo stesso motivo,
dovrebbe essere raggruppato insieme
◆

Esempi
• Codice relativo al framework
• Codice relativo ad uno specifico servizio
• Codice relativo al dominio

L'importante distinzione tra dominio e infrastruttura
Domain
• Modelli: entitá, value object o altro
• interfacce per I boundary objects
Infrastructure
• framework
• implementazione per boundary objects
• Web controllers, comandi CLI
Application
• Use cases

Perché é cosi importante avere un
software mantenibile?
◆

Le porte sono come i contratti
Non hanno rappresentazione nella codebase
 
C’é una porta per ogni use case dell’applicazione o codice che
interagisca con essa.
Ci sono porte di input e di output.

Input ports
interface PayOrderHandler
{
public function handle(PayOrderCommand $command): void;
}

Output ports
interface UserRepository
{
public function save(User $user): void;
public function findAll(): UserCollection;
}

Adapters definizione
Gli adapter sono le implementazioni delle porte, perché per ogni
porta abbiamo bisogno del codice che implementi i metodi.

Adapter esempio
class MysqlUserRepository implements UserRepository
{
/**
* @var Connection
*/
private $connection;
public function __construct(Connection $connection)
{
$this->connection = $connection;
}
public function save(User $user): void
{//do stuff...}
public function findById(UserId $userId): User
{//do stuff...}
public function findAll(): UserCollection
{//do stuff...}
}

Esempio di struttura di un progetto
Src
Payment
Domain 
Application
Infrastructure
Cart
Domain
Application
Infrastructure

Dependency inversion principle

Vantaggi nell’uso dell’architettura
esagonale
◆

Puoi sostituire un implementazione senza toccare il dominio
3

Puoi prendere decisioni implementative piu tardi 
come: vendors, databases, servers, etc…
4

Puoi aggiornare vendors e framework senza toccare il codice di
dominio.
5

Puoi creare applicazioni mantenibili
6

namespace AppUserInfrastructureController;
use AppUserApplicationCreateUserService;
use AppUserApplicationDTOCreateUserRequest;
use SymfonyComponentHttpFoundationJsonResponse;
use SymfonyComponentHttpFoundationRequest;
class UserController
{
public function saveAction(Request $request, CreateUserService $createUserService)
{
$createUserRequest = CreateUserRequest::create($request->request->all());
$createUserService->createUser($createUserRequest);
return new JsonResponse();
}
}

namespace AppUserApplication;
use …
class CreateUserService
{
private UserRepository $userRepository;
public function __construct(UserRepository $userRepository)
{
$this->userRepository = $userRepository;
}
public function createUser(CreateUserRequest $createUserRequest): CreateUserResponse
{
$user = User::create(
$createUserRequest->getName(),
$createUserRequest->getPassword()
);
$this->userRepository->save($user);
return CreateUserResponse::createFromUser($user);
}
}

Quando usare questa architettura?
• Quando avete un progetto nuovo
• Quando devi sviluppare un nuovo contesto in una applicazione
legacy
• Sempre?
When to use it

Ma qual é l’approccio ai progetti
legacy che non usano
l’architettura esagonale?
◆

Regola d’oro
Regola del boy scout: 
Lascia il tuo codice migliore rispetto a come l'hai trovato.
When to use it

Da dove possiamo partire?
• Usare piu interfacce possibili
• Usare la dependency injection
• Fare pratica con dei kata
• Applicare l’architettura esagonale a progetti reali
When to use it

Ulteriori miglioramenti
- DDD: Domain driven design
- CQRS pattern (Command Query Responsibility Segregation)
- Event sourcing
- TDD
- BDD
When to use it

Hexagonal architecture ita

More Related Content

Similar to Hexagonal architecture ita (20)

More from Alessandro Minoccheri (8)

Hexagonal architecture ita