Come aggiornare gli attributi su un'entità dal contesto delimitato remoto?

1

Vedo molte indicazioni nella comunità DDD su come recuperare e utilizzare le informazioni da un contesto limitato remoto (usando un livello anticorruzione, un servizio host aperto, ecc.), ma quasi nulla su come gestire l'archiviazione degli attributi che importa nel contesto locale limitato per un'entità che ha la sua sede in un contesto limitato remoto.

Ad esempio, la nostra schedulazione BC ha una Client , e nel nostro Contabilità BC abbiamo solo bisogno di alcuni dei suoi attributi. Abbastanza facile, basta prenderlo attraverso un livello anticorruzione che crea per noi un Client ridotto.

Ma dobbiamo anche gestire l'aggiornamento dell'indirizzo di fatturazione per Client , e la mia comprensione è che una rappresentazione BC a valle di un'entità BC a monte dovrebbe essere di sola lettura. Ma è il Contabilità BC a occuparsi dell'indirizzo di fatturazione, e non chiederemmo nemmeno un indirizzo di fatturazione senza la contabilità BC in atto.

Quindi non ha senso che il Contabilità BC sarebbe quello che gestirà la memorizzazione di queste informazioni? Se sì, come?

Questo è solo un esempio, ma sembra un modello comune, non è vero? Sono sicuro che sia stato discusso da qualche parte, proprio non riesco a trovarlo.

Aggiornamento: Questa domanda arriva proprio al problema che mi riguarda, anche se al momento non ci sono risposte soddisfacenti.

    
posta Kevin Smith 16.10.2018 - 22:51
fonte

1 risposta

2

Ho inviato questa domanda a Vaughn Vernon, ed è stato molto utile in risposta. Ha pubblicato le sue risposte qui sotto per i posteri.

In sintesi: dopo aver chiarito le sue intuizioni, mi sono reso conto che Scheduling BC è il sistema di record per Client , e il Contabilità BC gestisce il ciclo di vita di un'entità Client separata in questione con Informazioni di fatturazione. Se in Contabilità sono necessarie informazioni di Client da Pianificazione, è possibile eseguire la sincronizzazione su out-of-band.

From what I know, which from your question isn't much, it's two different objects. When modifying the local object you need a way to reflect dependent modifications on the remote object. Domain events can communicate the need for compensating modifications, but hopefully !1:1.

- @VaughnVernon

Ho quindi chiesto: Un BC dovrebbe avere autorità sul ciclo di vita (specialmente riguardo alla persistenza), o dovrebbero entrambi gestirlo a modo suo? (Sembra che siano in effetti 2 oggetti separati, ognuno dei quali rappresenta aspetti diversi di un Cliente.)

Separate. Compensating updates are eventual. If the business requires single transactional consistency for both then it's the same context and aggregate and separation of strongly consistent attributes is wrong. [emphasis added]

- @VaughnVernon

Il testo in grassetto è ciò che ha fatto clic su di me. Pensarci in termini di coerenza transazionale rivela se ho tracciato il contesto limitato (o anche i confini aggregati) nel posto giusto.

Ho quindi chiesto: Dato che un BC riguarda solo i concetti (e quindi gli elementi, gli attributi, ecc.) che contano all'interno di quel BC, sembrerebbe quindi inappropriato avere un master Client in un singolo BC che memorizzi tutti attr, anche attr che a BC non interessa. Ho ragione?

There is certainly a system of record for one of the two that exists first, and may ultimately impact the lifecycle of the second, but it doesn't "control" the updates to the second because they are separate languages.

- @VaughnVernon

    
risposta data 17.10.2018 - 17:18
fonte

Leggi altre domande sui tag