Un modello di dominio anemico significa che non è possibile utilizzare classi di utilità/supporto come "helper" per il modello di dominio?

Question

Secondo this definition, il concetto di Fowler di Anemic Domain Model è: modello di dominio

un software in cui la logica di business è implementato al di fuori oggetti del dominio

e

Con questo schema, la logica è in genere implementata in classi separate che trasforma la st mangiato del dominio oggetti. Fowler chiama tali script di transazioni di classi esterne .

Se prendiamo l'esempio di un carrello, l'oggetto Cart è l'oggetto dominio. Ma per elaborare il carrello fino all'ordine finale e la ricevuta è necessario controllare l'inventario dell'ordine e elaborare il pagamento con carta di credito. Molte di queste cose richiedono classi di utilità poiché fare tutto solo all'interno dell'oggetto Cart significa che la classe Cart sarebbe enorme e ingombrante. Ciò significa che il carrello in questo esempio sarebbe un modello di dominio anemico e queste classi di utilità sarebbero "script di transazione" in base alla definizione sopra riportata?

Answer 1

Un concetto chiave di progettazione basata su domini è quello di creare un design ricco che trasmetta e rispecchi il gergo dei suoi esperti di dominio (utenti aziendali). Quindi, vuoi che il tuo codice diventi un'espressione di quel modello di dominio. (vedi "Linguaggio onnipresente" e "Progettazione guidata dal modello" nello DDD Patterns summaries).

Quando si esegue questa operazione, verranno creati nomi per le entità (classi) che riflettono il modo in cui un utente aziendale può descriverle. Inoltre, creerai metodi su quelle classi che riflettono anche il dominio.

Con questo in mente, può essere utile considerare come si pensa alle classi di "aiuto" o "utilità". Utilizzando alcune delle vostre descrizioni, si potrebbe avere classi e metodi, quali:

product = GetProduct(data.productId); 
shoppingCart.add(product); 
receipt = customer.Purchase(shoppingCart); 

Il tuo metodo Customer.Purchase potrebbe fare cose come:

creditCard = this.getCreditCart(creditCardNumber); 
purchaseNumber = creditCard.Charge(shoppingCart.Total); 

mi rendo conto questi esempi non sono complete o addirittura completamente accurata ma spero che l'idea sia utile.

In risposta alla tua domanda originale - Sì, è OK avere un programma di utilità di supporto. Tuttavia, si desidera creare tali classi di supporto e associarle a entità di dominio reale. Dopo un po 'di lavoro con i tuoi utenti, sarai probabilmente in grado di creare entit di dominio significative che sono più che entità di script di transazione.

Spero che questo aiuti. In bocca al lupo!

Answer 2

Come ha affermato Chris, è utile avere un'utilità di classi di supporto se tali classi di supporto sono mappate a entità di dominio reali scoperte dalla lingua dell'utente. A volte molte "classi di aiuto" sono un sintomo di un modello anemico se sono correlate a classi che hanno principalmente setter & getter (in quegli scenari gli aiutanti crescono dal comportamento che non è correttamente assegnato agli oggetti del dominio).