Associazioni di modelli di dominio che non richiedono il comportamento dell'oggetto associato. Come modellare?

D: Perché gli oggetti si rimettono in contatto?
A: Per rendere il modello coerente e valido.

Proviamo a modellare il tuo dominio. Supplier è un aggregato. Customer è un aggregato. Suppliers sono creati e gestiti nel loro contesto limitato. In questo contesto posso create/update/delete/enable/disable fornitori.

Customers sono gestiti nel loro contesto limitato. Qualsiasi cliente deve essere associato a un determinato fornitore. Perchè lo chiedi? perchè è quello che ci hanno detto gli esperti del dominio. Pertanto, ogni volta che viene creato un cliente, gli passerò un oggetto con valore supplierId .

Ma fornitori e clienti non hanno bisogno di qualcosa l'uno dall'altro? In realtà lo fanno. Ognuno di essi deve essere valido e coerente nel sistema. Un Customer deve essere associato a un certo Supplier per essere un cliente valido.

Quando devi eliminare un Supplier , lo eliminerai nel suo contesto limitato e invierai un evento di dominio al contesto limitato di Customer con l'id del fornitore. Recupererai tutti i fornitori associati a quel fornitore e li cancellerai.

Ricorda la regola dell'aggregazione per transazione.

Nel caso in cui hai modellato tutto come un singolo contesto limitato, nel tuo servizio applicativo avvia la transazione, preleva il fornitore dal suo repository, lo elimina, recupera i clienti associati dal loro repository, li elimina e quindi esegue il commit della transazione.

Potrebbe essere veloce e sporco, ma potrebbe essere sufficiente per le tue esigenze.

A volte un oggetto non usa le proprie relazioni. Un cliente non usa sempre il suo fornitore nel codice, ma altri lo vogliono usare. E mettendo la relazione nel tuo modello di dominio, permetti un accesso facile e veloce a questa relazione.

Quando non si utilizza la relazione, potrebbe essere meglio richiedere il fornitore dal repository.

Ma parli anche dell'eliminazione del cliente quando il fornitore viene eliminato. Se stai usando un ORM, le modifiche possono farlo per te, ma probabilmente avrai bisogno di avere la relazione nel tuo modello di dominio (se mapperai anche il tuo modello di dominio direttamente nel database) (Questo è almeno vero per Hibernate (java) / NHibernate (.NET)). Quando scrivi tutte le query del tuo database a mano, non importa molto.

Quindi penso che sia solo una questione di convenienza rispetto a un modello di dominio puro.

Questo sarebbe un esempio di associazione transitiva, attraverso un oggetto di associazione come un ordine o una fattura che fa riferimento sia a Clienti che a Fornitori. Se non si dispone di tali oggetti, il modello è probabilmente incompleto o scomposto oltre il punto di utilità.

There is a relationship that a supplier can have many customers, and a customer (in this case) can only have one supplier.

Sicuramente c'è un motivo aziendale per te per dirlo. Perché è necessario che un cliente abbia un solo fornitore? C'è qualche invariante fondamentale che devi applicare? C'è qualcosa che puoi fare a un fornitore che interesserà tutti i clienti?

Generalmente un esperto di dominio presenterà una regola del genere a causa di alcuni principi di base. I tuoi esperti potrebbero non rendersi conto che non è ovvio per te perché la regola esiste, quindi devi comunicare con loro! Quando arrivi al principio di business sottostante, è quello che dovresti provare a rappresentare nel tuo codice.