Esiste uno schema per trattare un caso coerente diverso da tutti gli altri?

C'è un modello per il tuo caso, ed è chiamato Separation of Concerns.

Devi dividere la classe Client in due entità separate. Uno che le prenotazioni sono fatte con / contro e una separata per la segnalazione. Ai fini di questa risposta, li chiamerò Venue e Client .

Ogni Client possiede uno o più oggetti Venue . Capita solo che al momento tu abbia solo un Client che possiede più% oggetti di% co_de, mentre tutti gli altri ne possiedono solo uno.

Ho affrontato esattamente questo problema quando lavoravo come sviluppatore di applicazioni MIS per un analista di segmentazione di mercato. Eravamo abituati a lavorare con i negozi mom e pop e quindi il nostro vicepresidente delle vendite decise di iniziare a puntare su grandi operazioni di catena commerciale, che hanno più negozi.

La risposta semplice e ovvia è aggiungere una nuova entità di dominio al modello. Usando la tua terminologia, chiamiamola Office.

Ogni cliente ha uno o più uffici. Sembra che la maggior parte dei tuoi clienti abbia esattamente un ufficio, il che è del tutto soddisfacente; per queste persone, si desidera mantenere una separazione tra Office e Client perché (a) qualsiasi client può aggiungere un ufficio secondario in qualsiasi momento e (b) le entità Client e Office hanno attributi diversi. Un cliente può avere un indirizzo aziendale, mentre solo un ufficio avrà un indirizzo di spedizione, per esempio. Questa distinzione può diventare importante in modi che non puoi prevedere, ad es. se ci sono implicazioni fiscali diverse per posizione o se la forza vendita presenta una struttura di commissioni che distingue tra clienti e uffici, quel genere di cose.

Evita la tentazione di unire le cose insieme o di trattarle come genitore / figlio in una sorta di struttura gerarchica. Non sono genitori e figli, sono entità aziendali distinte a sé stanti con diversi attributi e comportamenti.

Se utilizzi questo approccio dovresti essere in grado di utilizzare una logica identica per lavorare con un cliente che ha un ufficio, due uffici o 100 uffici.

Per essere onesti, è un po 'preoccupante pensare alle affermazioni if / else quando "si confrontano" con un simile scenario.

Fortunatamente, ti rendi conto che è la strada sbagliata da fare.

Non esiste un modello che si adatti alla tua soluzione, come un intero paradigma: si chiama Domain Driven Design o DDD in breve e quello che in pratica dice è che il tuo sistema dovrebbe essere modellato secondo la realtà.

Mi è già chiaro che hai a che fare con due entità che hanno una relazione uno-a-molti tra loro, ma il sistema conosce al momento solo una entità (che tu chiami Client ).

La prima cosa che dovresti fare è scavare in quali entità hai esattamente a che fare. Client sembra piuttosto vago. Ad esempio potresti finire con ClientCompany e ClientOffice . Quindi, ClientCompany è ciò che stai segnalando contro, e Booking s sono allegati a ClientOffice s. Ma senza ulteriori informazioni sul tuo sistema e casi d'uso, è difficile dire quale dovrebbe essere il tuo dominio .

Se questo significa un cambio di progetto piuttosto grande, la reazione standard sarà

"But... that's way too much work! We need to support it next week!"

Devi solo rendertene conto, se scegli un altro percorso oltre a questo per rendere meno lavoro ... Dovrai fare doppio / triplo / ... per correggere qualsiasi errore che stai per fare.

Buona fortuna!

La soluzione semplice è consentire ai client di avere client secondari.

Quindi ogni ufficio regionale è il proprio client, mentre è ancora possibile combinare tutto come totale per il client di grandi dimensioni.

Gli altri client sono solo client senza client secondari.

Ciò consentirà anche di raggruppare gli uffici regionali se ciò sarà necessario in seguito.