Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

User Auth in EventSourcing applications

I'm looking into crafting an app with DDD+CQRS+EventSourcing, and I have some trouble figuring out how to do user auth.

Users are intrinsically part of my domain, as they are responsible for clients. I'm using ASP.NET MVC 4, and I was looking to just use the SimpleMembership. Since logging in and authorising users is a synchronous operation, how is this tackled in an eventually consistent architecture?

Will I have to roll my own auth system where I keep denormalized auth tables on the read side? How to handle the security of this? Will I end up storing password hashes in both my event store and my view tables?

So many questions, if anyone can shed some light, I would be very thankful :)

tldr; How do you do User Auth in EventSource-applications?

like image 206
tuxbear Avatar asked Mar 26 '13 15:03

tuxbear


People also ask

What is the difference between CQRS and event sourcing?

CQRS is implemented by a separation of responsibilities between commands and queries, and event sourcing is implemented by using the sequence of events to track changes in data.

What is the difference between event driven and event sourcing?

Event Sourcing is about using events as the state. Event Driven Architecture is about using events to communicate between service boundaries.

How do you implement event sourcing in Microservices?

Event sourcing persists the state of a business entity such an Order or a Customer as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic.

What is event sourcing example?

Good examples for Event Sourcing are version control systems that stores current state as diffs. The current state is your latest source code, and events are your commits.


1 Answers

Not every "Domain" or business component has to use DDD or CQRS. In most cases, user information is really cruddy, so you can usually not use DDD for that. Other domains don't really depend on the actual user. There's usually a correlation id (UserId) that gets shared by the various domains.

If using messaging in your system, one option is to register and manage users without CQRS, then send a command (RegisterUser { UserId } ). This would publish an event User Registered. Other domains can listen to this event to kick-off any workflows or ARs that are needed.

like image 105
Jonathan Matheus Avatar answered Sep 29 '22 08:09

Jonathan Matheus