Recentemente mi sono posto una domanda sul fatto che un semplice calcolo debba essere inserito nel livello Entità, o l'Entità dovrebbe essere pura per la semplice memorizzazione dei dati grezzi e lasciare le logiche di calcolo nel livello aziendale.
Quindi la mia domanda è se sia ragionevole incapsulare calcoli semplici nelle proprietà in una classe di entità?
Dipende dal tipo di architettura che desideri.
Ciò significherebbe che un Order ha una proprietà (o un metodo) che restituirebbe il prezzo totale dell'ordine basato sul OrderLines . Il Order avrebbe anche un metodo AddOrderItem(Product product, int amount) e il Order controllerebbe se esiste già un OrderLine per quel prodotto specifico.
In questo modello avresti anche oggetti che non sono entità reali, come Repository per l'accesso ai dati o Factory per la creazione di entità. Questi sono chiamati servizi di dominio. Un livello applicazione è responsabile della chiamata ai servizi di dominio (ad esempio per recuperare un'entità dal database) e quindi eseguirà la funzionalità sull'entità. Il Application Layer dovrebbe essere il più sottile possibile.
Questo è un bell'articolo su DDD che spiega questi concetti in maggior dettaglio.
Order e il controllo di un duplicato% diOrderLines. Ci sono opinioni diverse sul fatto che un modello di dominio anemico sia una cosa negativa. Personalmente preferisco un vero modello di dominio.
Questo articolo descrive le differenze tra un modello di dominio anemico e non anemico.
Bene, entità e oggetti business sono quasi gli stessi, il più delle volte. Ad esempio se si dispone di una classe di prodotto e si desidera esporre una proprietà che prende alcune proprietà esistenti nella classe di prodotto e esegue alcuni calcoli e quindi la espone. È corretto nel senso che, la logica di creare quella proprietà rimane con la classe.
Ora potrebbe venire la domanda, dove inserire la classe del livello aziendale. Preferisco usare la classe del livello aziendale che ha qualche logica per affrontare il problema aziendale. Ad esempio nell'esempio di prodotto, un problema aziendale potrebbe essere la ricarica di denaro utilizzando un fornitore di terze parti come PayPal.
Una cosa fondamentale da ricordare è che un'entità avrà sempre un'identità, ma un oggetto aziendale è un'entità senza un'identificazione. Ad esempio, il prodotto è un'entità, ma il denaro non avrebbe un'identità. 1000 diverse istanze di denaro sarebbero uguali.
Leggi altre domande sui tag design-patterns