Modella le preferenze del cliente con diversi prodotti per i venditori

Dal punto di vista del DDD, la prima cosa che devi identificare è il contesto Limitato in cui questa funzionalità dovrebbe risiedere. Avanti sono gli invarianti di business, se del caso. Dopo tutte queste analisi strategiche puoi andare avanti per prendere decisioni tattiche come quello che gli oggetti aggregati, le entità e il valore da costruire.

Da quello che vedo questa funzionalità dovrebbe rimanere in un contesto UI , Presentation o Session sub-bounded poiché è qualcosa di specifico per il dominio eXperience dell'utente. Non cambia il modo in cui funziona l'Ordine o l'Inventario.

Non vedo invarianti di business complessi che devono essere protetti.

Quindi, questa nuova funzione dovrebbe risiedere in un nuovo modulo o sottomodulo o spazio dei nomi. Una semplice CRUD dovrebbe essere sufficiente: CustomerShoePreferences con riferimenti a CustomerId e ProductId e con oggetti Valore che descrivono quantitativamente l'entità (colore, dimensione ecc.)

Come puoi vedere, anche se non hai utilizzato l'intero arsenale di blocchi DDD bulding, come Aggregates, il design strategico di DDD può aiutarti a trovare la migliore architettura per il tuo caso d'uso.

Tuttavia non sono ancora del tutto chiaro con i requisiti, ma posso capire il dolore dovuto al fatto che ShoePreference come parte di Customer è migliore per elaborare una modellazione generica. Posso visualizzare qualcosa di simile qui sotto:

IPreference{

Dictionary<string, List<NameVauePair>> GetPreference();} 

/*ex : shoes, new List{ new NameValuePair{Name = "Color" , Value="Black"} */


class Customer
{
    public List<IPreference> Preferences {get; set;}
    ...
}

PreferenceEvaluator(customer cust){

var preferences = cust.GetPreference();
/* logic to match preference */}

Questa è una situazione in cui qualche pensiero sul modello relazionale potrebbe effettivamente aiutarti. La soluzione più semplice sarà quella di memorizzare tutte le preferenze in una singola tabella in cui un'entità Preference avrà una chiave composta naturale su [customerId] , [sellerId] , [productId] e [preferenceName] . Se si memorizza una gerarchia di preferenze per un singolo attributo (ad esempio Nero - > Blu - > Rosso), potrebbe essere necessario aggiungere un altro campo alla chiave: [rank] . Ci sono altre possibilità che coinvolgono le gerarchie di tabelle, ma porterebbero naturalmente al modello di dominio che stai cercando di evitare.

Quindi, tenendo presente quanto sopra, l'implementazione più ovvia è di avere un singolo List<Preference> iniettato in ogni Customer che può essere filtrato in base a uno degli attributi sopra elencati.