Ripristino di un modello di dominio anemico in un'architettura a più livelli

Naviga le tue risposte
3

Ho passato gli ultimi giorni a studiare il design guidato da domini e a provare ad applicarlo a un progetto attuale. Ho scomposto il dominio del problema nei componenti logici canonici: dominio, infrastruttura e presentazione. Avendo completato un primo passaggio, ho fatto un passo indietro e mi sono reso conto che l'architettura che ho creato ha comportato praticamente tutta la logica aziendale contenuta nei servizi applicativi, che è il segno rivelatore di modello di dominio anemico odore di codice. Dopo un'ulteriore considerazione, la progettazione basata sul dominio potrebbe non essere la soluzione corretta per la mia applicazione, e anche se lo fosse, dato il numero limitato di regole di business logic nella mia applicazione, l'overhead di stratificazione potrebbe non valerne la pena . Dato che ho scritto solo UML e codice psuedo, non ho investito troppo tempo e sforzi, ma vorrei sfruttare ciò che posso se è possibile.

La mia architettura consiste di 4 componenti fisici:

  1. Il progetto "dominio": astrazioni e metodi CRUD per il tipo di dati che uso
  2. Il progetto "infrastucture": la rappresentazione logica e i metodi da eseguire sui dati
  3. Il progetto "presentazione": l'interfaccia utente (WinForms o WPF)
  4. Il progetto "servizi": coordina il dominio e gli oggetti dell'infrastruttura in base alle regole aziendali

Se dovessi utilizzare i componenti come progettato in architettura multilivello , il mio livello di presentazione manterrebbe solo riferimenti a 3 o 4 servizi per gestire tutte le funzionalità dell'applicazione. È un approccio valido?

    
posta Noren 11.10.2012 - 19:29
fonte

1 risposta

4

Penso che tu sia sulla strada giusta, ma potrebbe essere più facile capire la possibile nomenclatura diversa per ottenere una migliore comprensione del ruolo che ciascuno dei livelli giocherà nell'architettura.

L'articolo di Martin Fowler che hai collegato dove ha coniato il termine, Anemic Data Model era la sua critica al momento per l'architettura basata sulle transazioni e la tendenza a spingere completamente Behavior dagli oggetti dati. Essere un fedele sostenitore della programmazione e del design di OOP è una critica valida, poiché si preoccupa della sofisticazione del software che risale ai tempi delle strutture e della programmazione procedurale. Personalmente ritengo che sia piuttosto allarmista e questo non sarà un problema se la rigida aderenza architettonica alla progettazione di software layered e multilivello viene seguita in modo stateless e transazionale.

  1. Livello dominio consiste di oggetti dati che hanno la conoscenza e la capacità di persistere nel database o nel file

  2. Livello infrastruttura Questo potrebbe anche essere conosciuto come Livello di accesso ai dati . Le classi DAO stateless avranno la possibilità di recuperare gli oggetti dati.

  3. Propongo di avere un livello di logica aziendale separato. Qualsiasi e qualsiasi logica applicativa, logica di dominio speciale, interazioni con più DAO o servizi web esterni, integrazione di servizi di terze parti per soddisfare le regole di business e tutto in modo transnazionale stateless, sono tutti esempi di quale codice appartiene qui. Certo, alcuni di questi saranno semplicemente un wrapper per una singola chiamata DAO, ma la separazione tra preoccupazioni e basso accoppiamento è il vantaggio.

  4. Layer di presentazione Ci possono essere più livelli di presentazione, ma in genere sono gli arbitri della comunicazione di stato con i tuoi utenti. Un buon esempio di questo sarebbe il controller nell'architettura MVC. È in grado di mantenere un'interazione con stato e, laddove sono richieste operazioni logiche di business, dovrebbe essere semplice come chiamare le transazioni necessarie per recuperare i dati necessari o eseguire l'operazione necessaria. Esistono anche diversi tipi di presentazione, un client spesso o un server Web possono chiamare direttamente il livello della business logic, o forse la logica di business può essere completata da servizi Web che restituiscono i dati in una forma utile.

  5. Livelli di servizio Il livello di servizio dovrebbe essere privo di qualsiasi applicazione o logica aziendale e dovrebbe concentrarsi principalmente su alcune preoccupazioni. Dovrebbe racchiudere le chiamate del Business Layer, tradurre il dominio in un linguaggio comune che i clienti possono capire e gestire il mezzo di comunicazione tra il server e il client richiedente.

Sapendo questo e comprendendo i vantaggi del perché questo tipo di architettura transazionale potrebbe essere utile per te, dipende tuttavia interamente dal tipo di software che stai creando. Anche le domande sul numero appropriato di servizi non hanno senso in questo caso senza una completa comprensione dei requisiti tecnici e aziendali. È un approccio valido se si desidera costruire soluzioni di grandi dimensioni altamente manutenibili e scalabili con accoppiamento basso. Se stai costruendo un'applicazione più piccola con pochi interessi o obiettivi aziendali, forse è eccessivo.

    
risposta data 11.10.2012 - 20:22
fonte

Leggi altre domande sui tag

Esistono alternative all'utilizzo di un tipo facoltativo in un ambiente con multithreading? Ampio spazio nel mio curriculum come sviluppatore Java. Quali sono le competenze indispensabili per essere assunti quei giorni? [chiuso]