Esiste un nome di modello per i modelli di dominio che contengono il comportamento e lo stato minimo o nulla?

Sembra che tu abbia confuso dominio ricco vs dominio anemico con oggetti comportamentali rispetto a oggetti valore. Questi non sono nomi diversi per la stessa cosa. Queste sono quattro cose molto diverse.

• I domini ricchi sono pieni di regole aziendali. Ha un linguaggio tutto suo che un esperto di dominio si sentirebbe a suo agio a leggere ed esprimere anche se non è un programmatore.

quelli in contrasto con

• Domini anemici concentrati sulla manipolazione dello stato. In realtà sono ricchi domini in un modo bizzarro. Ma le regole aziendali riguardano esclusivamente l'aggiornamento del DB e il linguaggio del dominio è SQL. È meraviglioso se il tuo esperto di dominio è un DBA.

ma nessuno di questi è uguale a uno di questi:

• Oggetti di comportamento sono metodi raggruppati attorno a uno stato che li fa cambiare insieme o semplicemente al fatto che devono essere spostati insieme. Alcuni non hanno alcuno stato e va bene. Una bella borsa pratica di funzioni. Ciò che è sempre stato meglio raggruppare è che sono usati insieme. Che astraggono un'idea insieme. Dovrebbero raggrupparsi attorno a una singola responsabilità. Alcuni oggetti comportamentali si raggruppano attorno alle regole aziendali. Non tutti.

quelli in contrasto con

• Oggetti valore (come int, stringhe, stack, code, elenchi e praticamente qualsiasi cosa con getter) sono insiemi di dati che generalmente non si preoccupano dei loro valori. Forniscono metodi che espongono i loro dati o li misurano in qualche modo ma evitano accuratamente di prendere decisioni di comportamento in base ai loro dati.

Dove sei andato storto hai in qualche modo avuto l'idea che un dominio ricco non può avere oggetti valore e che uno anemico non può avere oggetti comportamentali. Il che è semplicemente sciocco. Certo, usare nient'altro che oggetti di valore rende difficile avere regole aziendali (diamine rende difficile fare qualsiasi cosa) ma gli amanti dei domini anemici non hanno certamente bisogno di allontanarsi dagli oggetti comportamentali per mantenere il loro dominio anemico.

Is there a pattern name for domain models that contain behaviour and little or no state?

Programmazione funzionale? Intendo davvero, chi te l'ha detto?

I notice that the answerers usually (well always) appear to suggest "rich" classes that contain behaviour with no or little state

Questo è tipico di un modello anemico di dati. Hai classi che definiscono i dati del dominio e hai classi che definiscono il comportamento del dominio. Le classi "ricche" raccomandate da Fowler sono un misto di entrambe.

L'apolidia è un'altra cosa. Una classe che ha stato è una classe in cui un valore di uno dei suoi membri può essere modificato dopo la costruzione. Se tutti i membri di una classe sono immutabili, la classe è senza stato. È quindi possibile implementare un modello di dominio interamente stateless utilizzando solo classi immutabili e io consiglio di farlo.

They use state when they can benefit from dependency injection for testing (which is good)

Secondo me, nella corretta implementazione del modello di dominio anemico, le classi comportamentali dovrebbero essere apolidi. Questo è ottenuto attraverso l'iniezione del costruttore. Quindi quando dici "usano lo stato" - questo è sbagliato. Loro fanno hanno membri di livello di istanza, ma non sono variabili (cioè sono immutabili). I membri possono essere "semplici" tipi primitivi, ma spesso hai ragione e sono interfacce.

My research and experience tells me that this could be because these simple types are not interfaces making them more difficult to work with from an automocking perspective.

Sì, a volte questo è vero. I tipi semplici sono un po 'più difficili da auto-iniettare perché a differenza delle interfacce avrai molte istanze dello stesso tipo concreto (ad esempio String ) ed è più difficile distinguerle, ma di solito c'è un supporto per la configurazione come questa nel tuo Contenitore DI. In Java, Spring ha l'annotazione @Value per l'iniezione di primitive dalla configurazione.

Secondo me, il modello di dominio non dovrebbe dipendere da una libreria o contenitore DI. È sufficiente definire i costruttori per le dipendenze da iniettare e disporre di una radice di composizione in cui vengono richiamati i costruttori.

However, when I read books they seem to recommend classes with state like this once: http://www.newthinktank.com/wp-content/uploads/2012/12/Object-Oriented-Design.png (notice that the state contains simple types).

Questo diagramma mostra un modello "ricco" in cui le definizioni di comportamento e le definizioni dei dati sono nella stessa classe.