Design basato sul dominio: fabbrica con preoccupazioni trasversali

Question

Design basato sul dominio: fabbrica con preoccupazioni trasversali

#1 da (0 voti)

1

Di recente mi è stato assegnato il compito di creare una fabbrica che elabora eventi di webhook. Qualsiasi applicazione autorizzata nella soluzione (1 app per dominio) può pubblicare qualsiasi carico utile significativo e finché l'evento è cablato per l'elaborazione dovrebbe essere in grado di gestirlo.

Ho due progetti di dominio: Core (logging, sicurezza e funzionalità comuni) e chiamiamolo App1. Idealmente, App1 dovrebbe sempre fare riferimento a Core, ma Core non dovrebbe mai fare riferimento a App1 per scopi di scalabilità (molte cose possono fare riferimento a Core).

La fabbrica ha il potenziale per chiamare App1, App2, App3, ecc ... quindi la mia domanda è: in che modo questi standard sono gestiti in un'architettura di progettazione basata sul dominio?

domain-driven-design solid factory

posta RandomUs1r 24.07.2018 - 22:50

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design solid factory

Come evitare scontri nell'elaborazione distribuita quando si esegue il polling del lavoro? L'attributo e la proprietà, il metodo e la funzione possono essere utilizzati in modo intercambiabile nel mondo del software?

score 0 · Answer 1

App1 should always reference Core, but Core should never reference App1

Questo plugin per le urla.

               AppN       |          Core
-----------------------------------------------------
                          |
    CommonResultUser    -- -|>     IOutputPort  
                          |             ^
                          |             | 
                          |             | 
                          |    CommonFunctionality
                          |             |
                          |             _
                          |             V
CommonFunctionalityUser -- -->     IInputPort
                          |

Il flusso del controllo attraversa tutto questo in senso antiorario. Si noti che tutte le dipendenze da codice statico passano da App a Core. Core non ha idea che le Apps esistano. Core fornisce solo interfacce che devono essere utilizzate per parlare e ascoltarlo.

La costruzione in main (che sa tutto) potrebbe essere simile a:

CommonFunctionalityUserInApp1 user = 
    new CommonFunctionalityUserInApp1(
        new CommonFunctionalityCore(
           new CommonResultUserInApp1()
        )
    )
;

Che sei libero di spingere in una fabbrica, se ne senti il bisogno.

L'uso potrebbe essere simile a:

user.commonProcedure();

E tutto questo potrebbe ricordarti questo:

Continuerò,manehogiàparlatoprima^{1 , 2}

Tutto questo presume che tu voglia veramente che AppN s non sia il centro dei loro rispettivi programmi e desideri davvero funzionalità comuni nel tuo core. In alternativa, è possibile spostare la funzionalità comune in una libreria. ^{3 , 4}