Come definire gli oggetti Rich Domain?

3

Sfondo: non sono riuscito a trovare una definizione standard per "modello di dominio ricco". Potrei chiamarlo non- modello di dominio anemico . Quindi, potrebbe essere definito come un modello di dominio del software in cui gli oggetti del dominio contengono poca o nessuna intensiva logica aziendale (convalide, calcoli, regole aziendali ecc.).

I modelli di dominio anemico sono ampiamente definiti nell'ERD. Ma, il modello di relazione di entità ovviamente non è sufficiente per gli oggetti di un dominio ricco. I modelli di dominio possono essere espressi in UML. Tuttavia, manca di rappresentazione per la logica aziendale (vincoli, regole, ecc.). Ho letto alcuni articoli su OCL che descrivono le regole per UML. Ma, non ho mai visto alcun uso industriale di esso.

Domanda: potresti suggerire un approccio per la definizione di oggetti con dominio ricco? Questo approccio dovrebbe concentrarsi su dati, vincoli e regole piuttosto che su classi e sequenze. Ad esempio, non voglio definire la classe Student con il metodo di registrazione. Voglio definire l'entità dello studente con alcune regole di iscrizione. Certo, potrei semplicemente definire le regole con qualche commento sul codice, ma cerco un metodo formale per questo.

Modifica: non mi aspetto una risposta del tipo "usa quello strumento, è meraviglioso". Mi aspetto esperienze e consigli su ad esempio creazione di DSL, profili UML, ecc.

    
posta Q Q 06.09.2016 - 10:32
fonte

2 risposte

1

IMHO l'approccio più popolare (almeno, attualmente) a questo è Domain Driven Design . Non sono un esperto di DDD, ma AFAIK la maggior parte della logica aziendale è descritta sviluppando un "linguaggio ubiquo" più o meno formalizzato.

    
risposta data 06.09.2016 - 12:53
fonte
0

Puoi utilizzare l'approccio "non strutturato" o "strutturato".

L'approccio non strutturato consiste nell'usare un linguaggio umano semplice per definire "regole" lungo qualcosa come UML per definire la struttura. Questo è generalmente semplice da creare e comprendere, ma richiede uno sforzo considerevole per trasformarsi in codice eseguibile.

Per quanto riguarda l'approccio strutturato, ci sono stati molti tentativi in passato. Direi che nessuno di loro ha davvero successo, perché prima o poi, potresti ricorrere a un linguaggio non strutturato. O passare alla scrittura del codice reale. ( related )

Questo è il motivo per cui per la maggior parte delle persone, "Rich Domain Model" significa "codice che rappresenta il modello di business e dominio".

    
risposta data 06.09.2016 - 12:12
fonte

Leggi altre domande sui tag