Getting Stuck with Bounded Contexts ...

[Michael Azerhad]

Hi, 

I practice DDD in my project.

Let's assume the boundedcontext IdentityAndAccessContext and MeetingContext.

Both contexts deal with the following terms:

• IdentityAndAccessContext has the notion of User class.
• MeetingContext has the notion of Participant class. (let's forget Creator for the example).

Participant represents the user in Meeting bounded context.

First, a User has to be created, leading to a UserCreatedEvent.
Then, in order to apply eventual consistency between those bounded contexts, the message is stored in the IdentityAndAccessContext and then sent through helps to an event listener and message queuing (still in the IAC context) to the MeetingContext, in order to create automatically the corresponding Participant.

It sounds like a good DDD design (IMO), however I come across an issue with this webapp's workflow:

• User is registering through a registration form and he's redirected to the home page.
• The home page needs some Participant values...and that's the issue:
  The process of eventual consistency might not finish before the redirection to home page, leading to "no values".

How to deal with this case?
Making the user wait before a notification of consistency? Bad UX no?
Inserting the Participant values in the same transaction of the User? ... violating Bounded contexts concept, wouldn't it?

[Michael Azerhad]

Actually, home page's  values depends on the Meeting Context database schema, so I can't just display some "cheats", in memory, to the client from the `User` object. This one being created BEFORE home page loads.

[Jimmy Bogard]

One easy way is don't do eventual consistency. Do immediate consistency instead. Don't have an async process with message queues dispatch out-of-band, dispatch to event handlers immediately, in-process, in the same transaction and in the same button click.

You can fake consistency with tricks at the UI layer (things like socket.io/signalr), but all are more complicated than simply getting rid of that queue.

--
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.
For more options, visit https://groups.google.com/d/optout.

[Bartłomiej Szczepanik]

IdentityAndAccessContext name of bounded context suggest you are familiar with `Implementing DDD` book, am I right? In this book you can find very similar use case (User vs Member afair) but the approach is a little different. MeetingContext's domain exposes Domain Service which has a method let's say `getParticipant`. This interface is implemented in ports & adapters fashion: it reaches IAA context using for example web service (REST) call and than translates the User into a Participant. 

All in all, I think you can simply inverse the control and instead of listening for events I would go for querying the other context for data you need. It's probably a little less efficient, but definitely easier to write.

[Michael Azerhad]

Hi Jimmy and Mequrel,

You're right, I took the name from IDDD book :)

I like this solution: making MeetingContext depending on IAAA context. 

Thus, each time the home page need to be reached, MeetingContext would ask for the User data in order to be create the participant. That sounds like a pretty context map.

However, it would involve an extra REST HTTP + database access call (in the IAA context)  each time the user displays the home page.

As the trick is only needed at the user registration time, isn't the advised solution would be more relevant to my use case? :

http://stackoverflow.com/questions/23061462/is-eventual-consistency-incompatible-with-user-authentication-process?noredirect=1#comment35262467_23061462

(I wrote the similar question in stackoverflow, since I'm really curious about the best strategy :))

What do you think of it?

Thanks a lot,

Michael

[Michael Azerhad]

Actually, I would add that the Jimmy's solution is really easy to implement and interesting, and especially it indeed makes sense to deal with immediate consistency in this case. 

Thanks