Modelli di dominio anemici e iniezione di servizi di dominio

19

Il modello di dominio anemico è descritto come un anti-modello nella progettazione guidata dal dominio da Martin Fowler. Per avere una logica aziendale sui modelli di dominio vengono spesso utilizzati i servizi di dominio. Ma l'iniezione di servizi di dominio in modelli di dominio è considerata dannosa da Vaughn Vernon (vedere "Implementazione del design guidato dal dominio, Pagina 387).

Secondo me quelle opinioni sono contraddittorie, è vero? Come possono essere considerati entrambi i punti?

È un modello di dominio davvero ricco con i servizi di dominio iniettati rispetto al modello di dominio anemico e ai normali servizi di dominio ?

domain-driven-design dependency-injection services

— Sjoerd222888
fonte

4

Non sono affatto un esperto in questo, ma pensavo che il tipo di logica che andava nei servizi di dominio e nelle entità di dominio fosse fondamentalmente diverso. La logica che entra nelle Entità è la logica necessaria per mantenere l'oggetto in uno stato corretto. Ciò comporta la convalida e la logica di trasformazione. I servizi di dominio, d'altra parte, sono per la logica di livello superiore. Quindi, ad esempio, un servizio di dominio modellerebbe un processo aziendale che coinvolge molteplici tipi diversi di entità è un modo complesso.

— MetaFight,

2

@MetaFight: anche se un processo aziendale influenza più entità in modi complessi, puoi farlo senza servizi, dato un buon modello di dominio di radice aggregata, cioè un modello di dominio che ha accesso a tutte le entità interessate come proprietà o campi su se stesso.

— Greg Burghardt,

Questo ha senso :)

— MetaFight il

16

Un modello anemico è semplicemente un contenitore di dati. Non contiene comportamenti. (Questo potrebbe effettivamente essere considerato una buona cosa nel paradigma funzionale.) L'opposto di un modello anemico non è un modello iniettato pieno di servizi di dominio. Stai descrivendo due estremi - entrambi sono cattivi.

Se hai un modello anemico, non stai completamente abbracciando ciò che offre OOP. Se inizi a iniettare servizi in quei modelli, probabilmente stai iniettando preoccupazioni che non vi appartengono. Questo o il tuo modello sono più anemici di quanto pensi. Perché altrimenti avresti bisogno del servizio diverso da quello che fornisce qualcosa che è richiesto ma mancante? (Manca potrebbe significare anemico.)

Evitare entrambi i "racconti" porta a un design più forte. Hai qualcosa in un servizio di cui un modello ha bisogno? Forse dovrebbe essere spostato sul modello. In caso contrario, forse dovresti riconsiderare le tue preoccupazioni. Il comportamento di un modello dovrebbe funzionare all'interno del modello. Dovrebbe principalmente (se non solo) interessarsi ai membri. Ma ricorda, ci saranno ancora cose che funzionano sul o con il modello. Ad esempio, i modelli non dovrebbero aprire connessioni TCP o ascoltare eventi dell'interfaccia utente, anche se in qualche modo sono coinvolti. Questa è la responsabilità di qualcun altro e che qualcuno non appartiene mai al modello.

— Scorpido Roger
fonte

7

Una buona distinzione che mi piace ricordare è che il tuo modello di dominio implementa la logica aziendale e i tuoi servizi di dominio eseguono la logica aziendale sui modelli di dominio. La differenza è chi sta chiamando chi. I servizi possono chiamare i metodi del modello di dominio. Se i modelli di dominio stanno chiamando i metodi di servizio, hai capovolto il modello sopra la sua testa.

— Greg Burghardt,

7

Non è contraddittorio. Entrambi i sostenitori vorrebbero che tu inserissi il tuo codice effettivo nell'oggetto dominio stesso.

vale a dire.

public class Order
{
    private string status = "not bought";
    public void Buy()
    {
        this.status = "bought";
    }
}

vs ADM

public class Order
{
    public string Status = "not bought";
}

public class BuyingService
{
    public Order Buy(Order order)
    {
         Order o = new Order();
         o.status = "bought";
         return o;
    }
}

vs servizi iniettati

public class Order
{
    public Order(IBuyingService bs)
    {
        _bs = bs;
    }
    private IbuyingService _bs;
    private string status = "not bought";
    public void Buy()
    {
        this.status = _bs.Buy();
    }
}

public class BuyingService : IBuyingService
{
    public string Buy()
    {
         return = "bought";
    }
}

Francamente ogni approccio ha vantaggi e svantaggi. Quello che scegli è in gran parte una questione di preferenze personali

— Ewan
fonte