Come verificare la dipendenza della chiave esterna in root aggregato ddd

Question

Come verificare la dipendenza della chiave esterna in root aggregato ddd

#1 da (3 voti)

4

Quando voglio chiamare un costruttore su un compito di classe radice aggregato, sono interessato come posso verificare se esiste un taskType passato nel repository TaskType (applicato successivamente in DB su livello ORM).

Voglio applicare questa relazione in modo che solo i tipi di attività predefiniti possano essere effettivamente utilizzati per creare un'attività.

È qualcosa che viene fatto in costruttore e validato in business logi di un modello di dominio, o questo tipo di convalida viene fatto solo in DB (aspettando un'eccezione DB se tale relazione non esiste)

class Task
{

     public Task()
     {
     }
     private int GUID {get;set;}
     public TaskType taskType {get;set;}

}

public TaskType
{
     public int ID {get;set;}
     public string TaskCode {get;set;}
}

Il codice viene utilizzato solo come esempio e potrebbe contenere alcune irregolarità.

design domain-driven-design design-patterns

posta Dario Granich 15.06.2016 - 09:36

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design design-patterns

Dovrebbe essere creato un metodo che si limita a delegare a un costruttore? Non capendo il concetto di come rendere la mia applicazione GUI

score 3 · Accepted Answer

Il più delle volte, non ha bisogno di sapere; gli aggregati con i contorni correttamente progettati non hanno bisogno di conoscere lo stato esterno per mantenerne l'invariante (che è fondamentalmente la definizione di un limite aggregato).

Quando un aggregato deve conoscere lo stato al di fuori del proprio confine, la solita risposta è un DomainService . L'aggregato richiama una query sul servizio e il servizio riporta la risposta.

I pattern di creazione sono strani, però - l'entità che stai chiedendo di mantenere l'invariante non esiste ancora. Puoi gestire il caso in due modi.

L'approccio che preferisco è usare uno stato comune per inizializzare l'aggregato, e quindi invocare un metodo su di esso per dare a questa entità un'identità unica. Questo si adatta al modello generale.

In alternativa, è possibile delegare la creazione dell'aggregato a una fabbrica. Fondamentalmente, questa è la stessa idea, con il confine della transazione disegnato in un posto diverso. L'esecuzione di base (richiede un servizio di dominio per verificare l'ultimo stato conosciuto del tuo stato esterno).

I want to enforce this relation so only predefined task types can be actually used to create a Task.

Se TaskType è un valore, puoi anche risolverlo quando traduci il messaggio CreateTask. Presumibilmente quel messaggio ha qualche bit di stato che identifica il tipo, quindi fai una ricerca su quello stato prima di creare l'aggregato. Questo è un modello di convalida dell'input di base.

In alternativa, è possibile inviare inizialmente il comando create a TaskType, che si copierà nel comando per creare l'attività. Concettualmente, ciò ha molto più senso se TaskType è un'entità, piuttosto che un valore, ma in entrambi i casi funziona. Vedi Non creare Root aggregati per alcune riflessioni su questo approccio.

Se TaskType è qualcosa che può "andare via", allora ci sono limiti reali a quanto il dominio può fare per garantire la tua regola. In molti casi, risulta che non è fondamentale per l'azienda che la regola venga seguita esattamente (ad esempio, l'incoerenza è rara, facile da identificare, economica da rimediare); in tal caso la bonifica anziché la convalida può essere più pratica.