OOP - Come rifattorizzare una "architettura piramidale"

Question

OOP - Come rifattorizzare una "architettura piramidale"

#1 da (5 voti)

3

All'insaputa di me mentre lo stavo costruendo, ho costruito un'architettura a "piramide". Non me ne sono reso conto fino a quando non l'ho esposto nel mio nuovo Visual Studio 2013 Layer Diagrammer. Ogni livello dipende dal livello sottostante, e tutti gli altri livelli sottostanti .

Sospetto che questa sia la causa di alcuni dei miei mali. Ogni livello superiore viola l'SRP, perché ha più di una ragione per cambiare, giusto? Ha più contratti con più livelli di base. Se uno qualsiasi di questi livelli cambia, il componente deve cambiare.

La mia domanda è, come posso refactoring questo? Sono 19.000 linee di codice, ma posso refactoring dato abbastanza tempo finché ho una solida strategia di refactoring.

E come nota a margine, invito anche le tue speculazioni sul motivo per cui ho sentito il bisogno di crearlo in questo modo. È un anti-modello? Ha un nome?

Modifica

Hobattezzatoquestoanti-pattern"The Garlic Architecture"

object-oriented anti-patterns architecture layers

posta toddmo 06.03.2015 - 18:35

fonte

1 risposta

Leggi altre domande sui tag object-oriented anti-patterns architecture layers

Garbage collection e perdite di memoria sulle tabelle hash abbonamento agli eventi delle classi nidificate

score 5 · Accepted Answer

In base alla foto che hai fornito, appare come Onion Architecture , ma con le dipendenze che procedono al contrario.

Una tipica architettura a cipolla è simile a questa:

Ognilivellopresentainterfacce(un'API)allivellosopradiessoecomunicaconillivellosopradiessoeillivellosottostante.Ilmodellodicipollapresentaalcunesomiglianzeconun'architetturaModel-View-Controlleroun'architetturaatrelivelli,masinotil'inclusionediunlayerTests,unlivelloInfrastructureeun"Inverter". Il modello di dominio comunica con un database (normalmente visualizzato come componente esterno a questo diagramma).

Il consulente da cui ho preso in prestito questa immagine lo descrive così:

For web-based enterprise applications, we espouse the benefits of a specialized hexagonal architecture known as Onion Architecture. The core principle of this architecture is to build the application around an independent object model that describes the business domain. Component coupling is unidirectional toward the center with separation between component contracts (interfaces) and implementations.

Understanding the structure of the architecture is simple. In practice, the architecture relies on the Dependency Inversion (DI) principle to assemble the components at runtime. We isolate the "Inverter" into a separate physical tier to avoid leaking responsibilities.