2

Our project is developed using DDD. We decided to move user identity to a single microservice that will be used to check user identity, issue and validate tokens.

Now, since accounts and users are located in a different microservice that is solving the problem of handling user and account details, we encountered a challenge called eventual consistency.

The question for us is should we first create account/users in accounts and users microservice and then publish event to user identity microservice or vice versa.

In first case, we will have account and users basic information immediately available, but no users will be able to login since no tokens can be provided due to eventual consistency delay.

In second case, user could login, but when he logs-in into his account, no account information will be available due to eventual consistency delay. For this case there is workaround of sending a confirmation mail when eventual consistency is met, so the user can confirm registration and login.

I would like to hear a feedback, which case makes more sense, and are there any problems I dont see at this point?

mko
  • 6,638
  • 12
  • 67
  • 118
  • 2
    I feel like seperating users from identity is rather weird. `User` is usually a concept found within the Identity BC. Anyway, if users login only with their identities, would they be able to use the core system features (except accessing their account infos obviously)? – plalx Jan 15 '17 at 01:12
  • Which approach did you take finally? – Ayyappa Jan 17 '22 at 12:54

2 Answers2

1

If a hammer is what you have, everything looks like a nail. It looks like you're trying too hard to apply grand ideas to a problem that doesn't warrant it.

When approaching problems using DDD it's vital to give thought to strategic DDD, i.e. the design part. A Bounded Context is where a particular language exists and manifests as implementation linked to a specific business capability.

Now it's your job to look at each BC to make a judgement as to what kind of architecture is appropriate for that context. The whole system doesn't, I should say shouldn't, have to follow the same implementation. Do you really need microservices for account\login creation? Sounds like you can get away with a CRUD-like implementation, doing away with any eventual consistency issues which you have introduced.

Keep it simple, sir.

Naeem Sarfraz
  • 7,360
  • 5
  • 37
  • 63
  • 1
    So basically you are saying I should merge the highest load microservice (which is user identity) with account and users ms in order to keep things simple? I just wanted to be able to scale properly. I noticed you mentioned CRUD cannot be a microsecond. I think that is a false statement. – mko Jan 17 '17 at 15:39
0

There is no need for an eventual consistency delay. The regiatrationCompleted event should only happen once all parts have been completed. This event is what your interface will respond to, trigger welcome emails and more actions like that.

Since different microservices can process events in parallel the time for this registrationCompleted event to be raised should be very short.

Logging in without account information is the worst of all options since you might run into security issues (like the account having certain rights or being locked).

Also note that a microservices is only as small as it can be, and no smaller. Of you can't reasonably handle a split case then you made it too small.

Batavia
  • 2,497
  • 14
  • 16