E’ da un po’ che in una certa realtà lo ripeto, ma non avevo mai trovato qualcosa di ufficiale a conforto. Adesso l’ho trovato.

In pratica vediamo perchè, scrivere l’interfaccia ICustomer sull’entità Customer sia sempre un errore. Sempre. Non in qualche caso. Perchè un entità non ha comportamenti. Un entità, per esempio “Customer” ritorna sempre la stessa cosa quando le si chiede, ad esempio, Name. Non c’è un algoritmo od una strategy che possa abbellire o rendere più intelligente il comportamento di Name. E’ poi interessante vedere come larchitettura diventa semplicemente oscena quando ICustomer ha per esempio un IAddress o qualsiasi altra reference…

Poichè è anche considerato un antipattern il Domain Model anemico ( cioè quello composto da sole entità  senza comportamenti) chi si ferma a leggere le prime righe di tutti gli articoli potrebbe pensare che piazzare su una bella interfaccia per ogni entità sia la soluzione. Questo non è però vero: vanno messi “dietro ad un interfaccia” i comportamenti che ha senso pensare che possano variare, ed eventualmente le entità potranno implementare una o più di queste interfacce di behavior. Per esempio Customer potrebbe implementare ICanPlaceHorder, e la logica con cui si piazza l’ordine potrebbe cambiare, ma le entità in gioco sono concrete.

Un interessante find storico sulla situazione è un caso pratico di Prima & Dopo.