Come dovrebbe un'entità che astrae un servizio esterno fare le sue operazioni?

Question

Come dovrebbe un'entità che astrae un servizio esterno fare le sue operazioni?

#1 da (1 voti)
#2 da (0 voti)

1

Sto creando un sistema usando alcuni principi del DDD e sono bloccato da un problema.

Per dare un po 'più di contesto su ciò che sto cercando di fare, lasciatemi prima descrivere di cosa tratta il sistema:

L'idea è di consentire ad un utente di un tipo specifico di servizio di essere in grado di integrare e testare molti di questi servizi senza integrare il suo sistema con tutti loro.

Per fare ciò l'utente si integra con il mio sistema, che funge da gateway, integrandosi con tutti quei servizi.

Ora lasciami spiegare il problema:

Per ogni servizio integrato c'è un'implementazione API molto specifica (alcuni usano JSON, altri XML) e per questo motivo queste implementazioni sono usate come dipendenze separate (progetti).

Nel livello del dominio, esiste un'entità denominata ExternalService , questa entità rappresenta un'integrazione del servizio supportata.

Diciamo che il tipo di servizio di cui stiamo parlando qui è un sistema SMS che invia messaggi a un numero di telefono.

Quindi abbiamo un'implementazione API che si integra con il servizio esterno:

class XYZSMSProviderApi {
    public void sendMessage(String phone) {...}
}

E abbiamo l'entità ExternalService con i dati del servizio XYZ (questi dati sono mantenuti in un database):

class ExternalService {
    public String name = "XYZ";
}

Il problema è: chi dovrebbe essere responsabile della chiamata al metodo sendMessage della classe XYZSMSProviderApi ?

Devo iniettare l'oggetto API nell'entità e quindi avere un metodo per inviare il messaggio effettivo nell'entità?

domain-driven-design architecture design-patterns

posta user27616 13.02.2016 - 23:32

fonte

2 risposte

1

Attenzione al detto " Se tutto ciò che hai è un martello, tutto sembra un chiodo ". Sei sicuro che il DDD sia adatto al tuo sistema? Dalla descrizione del tuo contesto:

The ideia is to allow an user of an specific kind of service to be able to integrate and test many of these services without integrating his system with all of them.

To do that the user would integrate with my system, which acts as a gateway, integrating with all those services.

Sembra che il dominio della tua applicazione sia in realtà molto snello, o almeno non molto facilmente identificabile con gli abituali adattamenti per DDD. DDD mira a supportare lo sviluppo di software aziendali di dimensioni medio-grandi, con molte regole aziendali complesse che devono essere mappate ai numerosi processi amministrativi e operativi dell'azienda (e molte altre aree), definendo il dominio come le astrazioni centrali comuni al sistema generale (dove le entità entrano in gioco).

Penso che puoi esaminare altri modelli architetturali che riguardano più l'integrazione di componenti esterni piuttosto che uno che si concentra pesantemente su astrazioni su grandi domini aziendali. Uno di questi modelli è seguire un'architettura di plugin, che fondamentalmente significa progettare API collegabili (un interface in Java, ad esempio) e consentire l'implementazione e / o la sostituzione delle implementazioni in fase di runtime o avvio dell'applicazione (c'è un po 'di informazioni generalmente utili su questa domanda e i suoi riferimenti) . Inoltre, puoi leggere altri modelli citati in questo post sul blog ; sono anche generalmente rivolti a domini più grandi, ma descrivono modi ben disaccoppiati per gestire dipendenze esterne che ritengo possano esserti utili.

risposta data 17.02.2016 - 04:48

fonte

Leggi altre domande sui tag domain-driven-design architecture design-patterns

Come posso gestire in modo pulito una serie di permutazioni della richiesta di risorsa, (facoltativo) Controllo accesso, Risultato risorsa? Come eseguire più intervalli temporizzati?

score 0 · Accepted Answer

Should I inject the API object in the entity and then have a method to do the actual message sending in the entity?

Probabilmente no. Il solito idioma è che il modello di dominio è responsabile dell'integrità del proprio stato / dati e nient'altro. L'integrazione con servizi esterni è un problema applicativo, non un problema di dominio.

Nei termini DDD, se ExternalService ("XYZ") è un aggregate nel dominio, il codice all'interno di tale entità riguarda principalmente l'invariante di business che deve essere applicato da quel pezzo del dominio. Altre preoccupazioni - vale a dire, che cosa fai con i dati ora che puoi essere certo che soddisfi tutte le tue regole aziendali - vivi da qualche altra parte.

Quindi l'applicazione interroga l'aggregato per ottenere lo stato di cui ha bisogno e l'invio effettivo del messaggio si trova nell'applicazione stessa.