If I understand the concept of read models correctly, then it's just a simple query to return a use case specific data set.
Non è giusto.
I DTO sono un artefatto di confine
an object that carries data between processes in order to reduce the number of method calls -- Martin Fowler, Patterns of Enterprise Application Architecture.
In questi giorni, quando tentiamo di evitare l'aggiunta di vincoli che intralciano client e server, è più probabile che usiamo una rappresentazione di un messaggio (byte) per superare un limite di processo. (Qual è la differenza? Inviamo i dati, ma non inviamo getter e setter sul filo). Quindi il "DTO" diventa la rappresentazione dell'oggetto di quei byte in questo processo.
I "modelli di lettura" appartengono concettualmente al nucleo: sono le parti del nostro modello di dominio che vengono scritte per fornire supporto per le query. Esse derivano dalla biforcazione logica del modello di dominio in responsabilità di interrogazione e responsabilità di mutazione.
Un modo per riconoscere la differenza: se i tuoi dati sono in primitive linguistiche (byte, interi, stringhe), probabilmente stai guardando un DTO. Se stai guardando concetti di dominio (numeri di conto, importi, SKU), allora sei più probabile nel modello di lettura.
(Non è perfetto, ovviamente, ci sono molti "anemici" e primitivo ossessionato modelli di dominio là fuori).
Should I use the read model for "simple" data queries, and DTOs for more complex situations like rich user interfaces?
Praticamente - se hai già una rappresentazione di dati adatta alle esigenze dei clienti, spediscila semplicemente - non c'è molto valore nel passare attraverso il modello di dominio. È particolarmente probabile che tu lo veda per le query che possono trarre vantaggio da una cache.
(Un modello comune prevede un processo di back ground che utilizza il modello di lettura per calcolare in anticipo le rappresentazioni utili per le query e archiviare i risultati in una cache: le query in tempo reale acquisiscono semplicemente la rappresentazione nella cache e vanno.
Non è del tutto sbagliato pensare a quel processo in background che usa il modello di lettura per calcolare le rappresentazioni DTO che sono memorizzate nella cache.
So my read-models that represent the search results should be part of the domain model? Feels weird because I was under the impression that search is just a simple service.
Sospetto che la confusione derivi dal pensare che i modelli letti esistono solo nei servizi. Non è vero - lo stesso modello si adatta anche alle applicazioni.
Se stiamo inviando una query attraverso un limite di processo, allora alla fine comunicheremo bytes , e se abbiamo già i byte di cui abbiamo bisogno, non c'è motivo di idratarli in una rappresentazione di dominio prima solo in modo che possiamo trasformarli nuovamente in byte.
Allo stesso modo, se stai rispondendo a una query con dati in un RDBMS, probabilmente trasformerai il ResultSet in byte, o il ResultSet in JSON in byte, o qualsiasi altra cosa. Certamente non hai bisogno di entità di dominio e probabilmente non hai nemmeno bisogno di valori di dominio.