Ho letto DDD rapidamente e mi sono chiesto come evitare di nominare scontri con termini tecnici e termini di dominio. Ad esempio, se ho comunemente utilizzato il modello di repository (con classi come AddressRepository), ma un cliente ha anche qualcosa chiamato repository nel proprio dominio. Come potrei evitare di confondere i due?
Direi che nello spirito del linguaggio Ubiquitous di DDD, la definizione Domain del termine di scontro dovrebbe avere la precedenza sul termine dell'infrastruttura di programmazione.
Nel tuo caso, se esiste già una definizione di dominio per "Repository", allora dovresti scegliere un altro nome per il tuo AddressRepository che non interferisce, anche se la classe sta implementando il meccanismo del repository DDD. Dopo tutto, non è avere per aggiungere "Repository" alla fine del nome della classe, è solo una comodità per te, il programmatore. Probabilmente lo chiamerei semplicemente "Indirizzi".
Nella maggior parte dei casi, quando esiste uno scontro puoi trovare con l'esperto del dominio un perfetto che rimuove l'ambiguità.
Quando non esiste, il problema non riguarda il codice base poiché il compilatore conosce gli spazi dei nomi (e btw nessun repository dovrebbe essere nello stesso modulo del dominio), ma il carico cognitivo degli sviluppatori.
In effetti, quando nuovi sviluppatori si uniranno al progetto, dovranno conoscere il significato "diverso" di "quell'unica parola" e impiegheranno del tempo per essere in grado di capire dal contesto se si sta parlando della tecnica concetto o quello del dominio (e credetemi, questo è sia fastidioso che costoso).
Quindi, suggerisco di
Potrebbe sembrare troppo pragmatico, ma funziona bene.
Leggi altre domande sui tag domain-driven-design