Dovresti leggere ulteriori informazioni su Domain Driven Design . Fondamentalmente si tenta di catturare i requisiti del business in un modello puro (in oop per lo più modelli di oggetti) che possono fare tutte le attività logiche di business necessarie. Questo modello può quindi essere richiamato da un livello applicazione (ad esempio la vista o il controller in MVC, in MVP lo si chiama e lo si regola per la GUI in un Presenter). Il modello dovrebbe anche ignorare la persistenza e altre cose tecniche possibili.
L'incapsulamento della logica aziendale in un modello di dominio di questo tipo presenta alcuni grandi vantaggi:
- Riusabilità
- Facilità d'uso ed estensione
- Generalmente porta a un'architettura migliore
- Comunica in modo chiaro le coerenze e i requisiti aziendali ...
- ... e quindi migliora la comunicazione tra sviluppatori, clienti, analisti ecc.
Raccomando il libro di Eric Evan su Domain Driven Design per ulteriori letture, in quanto ti indicherà il giusto direzione e darvi alcuni buoni esempi su dove mettere quale logica. Scommetto che quando lo avrai letto, una grande percentuale delle tue entità conterrà più di dati flat .
But I am finding it hard to plan out an approach in which Models
handle the business logic and are classes which are complete in
themselves.
Presumo che per modello ti riferisci principalmente alle entità in questo contesto. Mettere la logica aziendale / comportamento nelle entità non è un compito banale. Ma dovresti sempre pensare a quale entità è e che entità fa . Ha alcune responsabilità o comportamenti? A volte è ok avere entità piatte se i comportamenti o le responsabilità sono meglio espressi come servizi.
Supponi di avere un animale. Anche se i suoi attributi possono essere salvati in modo piatto in un database, anche questo ha un certo comportamento. Ha bisogno di mangiare. Ma un erbivoro non mangerà carne, quindi devi assicurarti che mostrerà il suo comportamento quando il programmatore vuole che consuma carne con la forza. Può muoversi e può rendere il proprio rumore unico. Queste sono alcune cose che dovrebbero essere modellate nell'entità, per esempio. Di certo non fare affidamento sui servizi procedurali per far mangiare, spostare o fare rumore gli animali.
Ma tutti gli esempi sono superficiali senza un concreto dominio aziendale. Quindi pensa al tuo dominio aziendale e alle sue entità, comportamenti e responsabilità. Un altro dominio aziendale può contenere entità che sembrano molto simili a quelle di un estraneo, ma che sono in effetti qualcosa di completamente diverso o che mostrano un comportamento completamente diverso. Il modello deve innanzitutto e soprattutto rappresentare il dominio dei suoi utenti il più accurato possibile.