Non conosco il "più efficace", ma trovo quanto segue utile.
Abstraction è la chiave e ha diverse dimensioni e dimensioni. Le astrazioni dovrebbero essere utili e complete e consentire al consumatore di definire e implementare un'altra astrazione nei termini di dominio che richiede.
Debito tecnico significa povere astrazioni; astrazioni che sono difficili da usare e astrazioni che sono incomplete in modo da richiedere al cliente che consuma le differenze necessarie e che così facendo si finisce per comprendere e affidarsi a un'implementazione sottostante più che desiderabile, che nella migliore delle ipotesi risulti più stretta accoppiamento e, nel caso peggiore, in spaghetti e / o zuppe!
In ordine crescente di dimensioni, un'astrazione può essere: una singola costante, un singolo metodo, un insieme di metodi, un'interfaccia e / o una classe, un pacchetto di interfacce e / o classi, un livello.
La stratificazione riguarda la creazione di astrazioni verticali che si appoggiano e si accumulano l'una sull'altra. Quando creiamo un'astrazione che fornisce esattamente i termini del dominio necessari per il prossimo programmatore (per creare il loro livello), è efficace all'isolamento. Un livello è un insieme di interfacce e / o classi che fornisce un insieme completo di entità, relazioni e comportamenti orientati al dominio. La stratificazione consente di separare i dubbi in modo che uno strato intermedio possa essere riprogettato senza disturbare i livelli superiori.
La creazione e il mantenimento della stratificazione man mano che il codice si evolve richiede una costante consapevolezza dei requisiti del dominio del consumatore consumante, del riconoscimento delle difficoltà del consumatore di uno strato a causa della mancata corrispondenza nei requisiti del dominio e del normale refactoring per creare e mantenere i livelli utili e completi.
Nel grande, il layering ci consente di cambiare tecnologia, come i linguaggi di implementazione.
Dobbiamo anche essere in grado di identificare quando stiamo attraversando i confini della responsabilità, come i confini organizzativi, dipartimentali o aziendali. I confini di responsabilità meritano un'attenzione speciale. Progettiamo astrazioni orientate al dominio appropriate a quei confini. Ai confini definiamo le orizzontali astrazioni che consentono a varie organizzazioni sia di esseri umani sia di sistemi automatizzati di riunirsi in un ecosistema più ampio.
Ad un certo punto, man mano che i nostri sforzi aumentano di dimensioni e portata, abbiamo bisogno di apparire solo dal codice in modo da poter parlare efficacemente dei nostri livelli verticali e dei nostri limiti orizzontali. Questa è architettura o architettura astrazione . L'architettura ci aiuta a collegare i punti tra i nostri requisiti e amp; intenzioni e scelte di design & implementazioni.
La centralizzazione combatte la separazione delle preoccupazioni, che a sua volta combatte una buona astrazione.
Un singolo database condiviso per tutta la persistenza può essere interessante per uno sforzo di piccole dimensioni, ma la co-locazione della persistenza rende molto facile per le applicazioni che hanno proprietà e responsabilità diverse accedere direttamente alle informazioni altrui invece di passare attraverso un confine orizzontale appropriato .
Un singolo motore di regole condivise raccoglie in modo simile la logica di business da quelli logicamente separati e crea interdipendenze di quelle regole che sono difficili da sfatare in seguito.