Un servizio CRUD di REST che accede a un DB ha 3 versioni del suo modello

I'm building a REST service [...] that does basic CRUD operations [...]

Questa è la chiave della tua domanda: se stai semplicemente facendo un semplice CRUD sulle tue entità con forse un po 'di semplice convalida, un modello di dominio ricco in piena regola è molto probabilmente eccessivo per la tua applicazione.

Suggerirei di iniziare con un modello semplice, anemico (annotato se necessario) e le corrispondenti classi / metodi di servizio CRUD. Se, in futuro, la logica del tuo dominio diventa più complessa, è tempo di refactoring.

A quel punto, è abbastanza probabile che questa mappatura 1-1-1 del modello di persistenza del dominio Web si interromperà comunque.

This seems like a lot of versions of the same thing, does anyone do things this way?

Sembra che molte versioni siano attualmente la stessa cosa.

Logicamente, hai davvero tre cose diverse in corso.

Hai la comprensione del modello del suo dominio. Parte della motivazione per investire gli sforzi nella modellizzazione del dominio core è che ne ricavate molti vantaggi competitivi. Desiderate un design facile da modificare, in modo da poter adattare rapidamente il modello a nuove conoscenze e nuove opportunità.

Hai la rappresentazione persistente; fondamentalmente, questo è un messaggio da una versione passata del modello al nuovo modello. La migrazione del tuo database per allinearlo con il tuo nuovo modello è potenzialmente costosa e introduce una forza contraria alle modifiche che vorresti nel modello.

In altre parole, hai una preoccupazione relativa alla retrocompatibilità. Non hai necessariamente bisogno di due diverse rappresentazioni, ma devi essere in grado di disaccoppiare il modello e la persistenza, perché in realtà stanno rispondendo a diverse forze per il cambiamento.

Tuttavia non è assolutamente critico; se non condividi i dati persistenti in modo promiscuo, puoi eseguire un esercizio di migrazione quando necessario.

La tua web api, tuttavia, ha un calcolo molto diverso. Come la persistenza, ha un strong requisito di compatibilità; ma ciò a cui l'API è accoppiata è altri consumatori, al di fuori del confine del servizio stesso. L'introduzione di un cambio di rottura qui è estremamente doloroso, perché devi iniziare a coordinare i cambiamenti tra le unità autonome separate.

Sono tre preoccupazioni logicamente distinte che oggi hanno forme coincidenti. YAGNI dice che non devi separare questi dubbi ancora . Chissà, forse il progetto non avrà mai abbastanza successo da giustificare il lavoro, o forse non avrai mai realmente bisogno di cambiare questa parte dell'app. Se le cose vanno a buon fine, è probabile che ne saprai di più domani su come apportare la modifica rispetto a oggi.

In altre parole: mantenere le implementazioni di queste preoccupazioni è un modo per introdurre il debito tecnico .

The savvy developer treats technical debt just as the entrepreneur does financial debt. They use it. It speeds delivery, so long as it is properly managed.