Quando i campi Oggetto business non devono riflettere esattamente le colonne del database

Potresti anche pensare a una rappresentazione alternativa. Considera gli oggetti usati dai client come "oggetti di interfaccia". Quindi un oggetto DAO può essere usato come un vero "oggetto business".

Gli oggetti business possono (e di solito devono) essere strettamente associati al database per comunicare con esso in un modo più efficiente.

Un oggetto di interfaccia, d'altra parte, forma un'API. Un'API ha i propri requisiti, che non si adattano necessariamente bene a ciò che fornisce DAO:

• Un oggetto DAO può esporre i dati, che non devono essere esposti ai client, come le password.
• Una rappresentazione dei dati DAO può essere diversa da quella richiesta dal cliente. Ad esempio, lo stesso campo password può essere hash nel database, mentre il codice client opera con una variante non hash.
• Un oggetto DAO può contenere dati non destinati alla manipolazione diretta da parte dei client. Di nuovo, una password può essere impostata durante la registrazione o verificata per correttezza, ma non letta.
• Un oggetto di interfaccia può spesso avere requisiti aggiuntivi applicati dal framework utilizzato, come JSF o RMI.

Penso che ci siano dei malintesi su alcuni dei termini che hai usato:

1. Il modello di dominio concettuale non è "oggetti di business utilizzati dai clienti". È un "modello" di quello, del dominio aziendale.
2. "Modello fisico" non è chiaro, cosa vuol dire. Quando qualcuno dice "fisico", non è necessariamente la terza fase della progettazione del database (dopo concettuale e logico). In genere se si sta parlando all'interno del contesto "modellazione del dominio", la mancata corrispondenza tra il modello e la parola fisica, si riferisce al modello concettuale e al dominio aziendale, non al database.
3. Se stai seguendo un approccio di progettazione basato sul dominio (specialmente con Hibernate che può creare automaticamente il database basato su modello di dominio e ORM), quindi prima devi progettare il tuo modello di dominio, quindi creare il resto dell'applicazione basata su di esso. In questo caso, il tuo database sarà guidato dal modello di dominio e non ci sarà discrepanza tra i due.

Dai un'occhiata a ibartis (mybartis.org) Quando lavoro con un modello di database che non riflette direttamente il modello di dominio, di solito uso ibartis invece di Hibernate.