User Interfaces, Inserting Data and Distributed Systems

[Daniel Lima]

Let's assume we have 3 systems (or contexts...or services) 

User Profile System: Manages information about user full name, bio, profile picture, gender and so

User Referal Systems: When users register themselves they have the option to inform a referral code that this system will manage in the future in other to give a reward to this user in case User X does something (e.g. places the first order above 100 euros)

User Account System: Holds information regarding the authorization/permission of the user to other systems. Stuff such as Login, Password, multi-factor authentication, login history, provides tokens etc.

Now, imagine I have a single User Interface that displays a form that aggregates data inputs for these 3 systems: A standard form with Name, Email, Password, Referral code, etc. When the user press "Submit" the data is stored in these 3 systems.

How do you guys usually do it? I mean

• Do you send a single message (payload) to the server and internally we distribute this big message across the multiple services?
• How do you manage failure? e.g. What if Inserting data on Referal and Account succeeds, but fails on Profile?

Do you guys have good articles regarding this topic? I can find a lot about UI composition for querying data, but not while inserting/updating data.

Thanks!

________________________________________

Daniel Lima

Software Engineer / Mentor / Consultant @ Amsterdam

Skype: yourwebmaker
Twitter: @yourwebmaker 

Facebook: /dlpinheiro

Talk: yourwebmaker

Github: yourwebmaker

[Rickard Öberg]

Great question! In our system (DDD/CQRS/ES based) we need to integrate roughly ten other services which do what you describe (customer support, referral, forums, etc.), and more. 

We have the main model ourselves, event sourced, so any updates are first checked against our “master copy”, so to speak. If the change is accepted it turns into one or more events, and then there are integration services that subscribe to those and update all the other systems asynchronously. The other systems are not allowed to reject changes, so any errors are purely system level (i.e. service down, network issues, etc.), and sync can then be safely retried. It really is pretty straightforward. 

I have no idea how to do it if the one UI change actually needs to update several systems synchronously, it does seem like a really hard problem to do it that way.

Cheers, Rickard

Sent from my iPad

On 12 Nov 2020, at 05:38, Daniel Lima <yourwe...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CANsufjhWxYP9h1O%2BMFoDZGtnx4N68awwwOW_2q_3KvmBRh5%3DVQ%40mail.gmail.com.

[Greg Young]

So ... it depends.

Where do you want to do aggregation?

Many times its you talk to many read models (imagine 3 services with 3 read models and I put them together in the UI).

Another option is to use a single read model and *do the aggregation in the read model*

Its not that one is right and the other is wrong its about tradeoffs. Obviously a readmodel off of 3 services is a bit more interesting than one to work with ... but its far easier to query. Having separate read models offers more flexibility but can be annoying to query.

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CANsufjhWxYP9h1O%2BMFoDZGtnx4N68awwwOW_2q_3KvmBRh5%3DVQ%40mail.gmail.com.

--

Studying for the Turing test

[Mauro Servienti]

Hi Daniel,

I wrote about it on the side of my ViewModel Composition series:

- https://milestone.topics.it/view-model-composition/2019/04/18/the-fine-art-of-dismantling.html

- https://milestone.topics.it/2019/05/02/safety-first.html

.m

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CANsufjhWxYP9h1O%2BMFoDZGtnx4N68awwwOW_2q_3KvmBRh5%3DVQ%40mail.gmail.com.

--

Mauro Servienti

[Tomas P.]

I would definitely do 1 request to the server with all the data and then one of the services needs to make sure that the storing succeeds in all the services or if it fails then it’s reverted.

Best Regards

Tomas

--

[mynkow]

I would do it with async calls to the services. No matter if you send one big message/api-gateway which hits the 3 services or the UI hits the 3 services. Question yourself if you want changing the name of the user to depend on changing the referral? Imagine you add an approval process for changing the referral. Something common in multi-level-marketing. If you make the 3 calls as a transaction you will introduce accidental complexity in the system. In other words you could handle it with an UX.

Ofc, there is no right or right approach. It all depends on the context and tradeoffs.

[Francisco Javier Estrella Rodriguez]

English:

I think in this case you should use the saga pattern. For me it is 3 different systems even though they have entities or data in common. You start the saga with an event and it will coordinate all the calls to the other systems.

Spanish:

Pienso que en este caso deberías usar el patrón saga. Para mí son 3 sistemas diferentes aunque tengan entidades o datos en común. Inicias la saga con un evento y ella coordinara todas las llamadas a los demás sistemas.