Downsides of managing users traditionally in otherwise event sourced application?

[Vasiliy Zukanov]

I'm writing a Java backend and decided to go with DDD, CQRS and Event Sourcing.

Currently, I have user management logic implemented according to Event Sourcing paradigms, but I start getting a feeling that it might be a non-optimal solution.

What I thought about is to decouple user management from the main application and implement it using the traditional approach, employing third party library like Apache Shiro. Such an implementation will effectively divide the application into two subsystems - traditional user management system, and Event Sourced business system.

Has anyone implemented such approach and can comment on whether it is a good idea at all, and what should I try to avoid?

[Greg Young]

I am not sure why it would be any issue? What issues do you see that may come up?

--
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+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Alexander Langer]

> Has anyone implemented such approach and can comment on whether it is a
> good idea at all

Almost all system we built used external third party tools for
authentication and authorization (I also used Shiro once) and the domain
logic is just referring to users by id. IMHO that's a classical
supporting subdomain where off-the-shelf solutions are a great fit.

I agree with Greg that's also not a problem to roll your own. Just make
sure you don't do stupid things such as storing plaintext or weekly
encrypted passwords (*) in the event etc.

Best,
Alex

(*) Even if you use a password hash function with N iterations/work
factor, where N is thought secure by today's standards, N iterations can
be insecure in 10 years. In a traditional CRUD approach you can simply
apply an additional number of iterations to update the stored hashes,
with ES you cannot.

[Vasiliy Zukanov]

I guess my worries can be demonstrated with the following example.

Let's assume that the following sequence takes place in the system:

1. User with id X executes action Y that requires "admin" privileges
   
2. The main system queries user management subsystem in order to ensure predicates: users X exist; user X has "admin" privileges
3. Action Y approved for user X
   
4. Event of type action_y_executed stored with the id of user X
   
5. Some time after that, user X looses "admin" privilege

Let's imagine that for whatever reason I need to revert system to the state right before action_y_executed event was stored. If I do that, the state of the main system is reverted, but the state of the user management subsystem is not. So if user X attempts to perform action Y after the revert, this attempt will be rejected due to missing "admin" privilege.

I don't really know if the scenario of reverting the system and replaying the input is something I would ever want/need to do, therefore I asked this question....

On Tuesday, July 4, 2017 at 6:38:00 PM UTC+3, Greg Young wrote:

I am not sure why it would be any issue? What issues do you see that may come up?

On Tue, Jul 4, 2017 at 1:00 PM, Vasiliy Zukanov <vasiliy...@gmail.com> wrote:

I'm writing a Java backend and decided to go with DDD, CQRS and Event Sourcing.

Currently, I have user management logic implemented according to Event Sourcing paradigms, but I start getting a feeling that it might be a non-optimal solution.

What I thought about is to decouple user management from the main application and implement it using the traditional approach, employing third party library like Apache Shiro. Such an implementation will effectively divide the application into two subsystems - traditional user management system, and Event Sourced business system.

Has anyone implemented such approach and can comment on whether it is a good idea at all, and what should I try to avoid?

--
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.

Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Greg Young]

Why not just use something like oauth2?

And even in this case can you not store the user in the metadata associated with the event given then apply compensating actions?

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Ramin]

This sounds like a very fabricated scenario. How would it be any different with decoupling? And finally, if the user loses admin privileges, it is for a reason and then she shouldn't be allowed to perform the action anymore, someone else would have to do that for her.

[Vasiliy Zukanov]

I will be using oauth or oauth2, but I don't see how the protocol details affect the general arch. What am I missing?

If I don't store users management events, then, to my best understanding, if I "go back in time" then the system (domain+user mgmt) will not be in the same state (e.g. privileges change described above).

In one of your talks you described how event sourced system can be debugged by spawning a copy of it, replaying events to a certain point in time, and then observing system's state and applying inputs in order to trace execution paths. However, if user mgmt is not even sourced, then the system might not be in the same state exactly. So I kind of lose the ability to perform this kind of debug, right?

If I go with event sourced user mgmt, then I can always "flatten" it into a standard approach. If I go with standard and then discover that I do need the history of users mgmt, then I'm screwed... Maybe worth erring on the safe side and go with even sourced and reconsider later?

Sorry for long questions, but I really need to understand this pattern.

Thanks

[Rickard Öberg]

Usually the debugging consists of getting to a particular state, and
stepping through adding the events that are problematic, seeing how
the state changes. If you want to actually perform new actions from
that state, and essentially discard all events after it (for the
purposes of debugging), that is a whole other ballgame, and involves
not only event sourcing users, but also making any kind of interaction
with any other thing replayable. Which is usually impossible or way
too much effort.

So if being able to get to a particular state and then step (which I
think is what most people do) is fine, then no, user management does
not have to be event sourced. If it's not fine, then user management
is probably the least of your concerns...

/Rickard

[Vasiliy Zukanov]

Thanks Rickard. 

Now it makes a lot more sense. Just to ensure that I got it right...

I can go back in time and replay events to a specific point. Then I can keep replaying events one at a time, or even insert non existend events and see what happens. However, I don't need an ability to apply inputs to the system in a "historical" state. 

Since I don't apply inputs, all the functionality that is involved in evaluation of predicates to events generation can be made non events sourced if that simplifies the design and is acceptable from domain point of view.

Does the above sound as a reasonable conclusion?

>>> email to dddcqrs+unsubscribe@googlegroups.com.

>>> Visit this group at https://groups.google.com/group/dddcqrs.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> Studying for the Turing test
>>
>> --
>> 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+unsubscribe@googlegroups.com.

>> Visit this group at https://groups.google.com/group/dddcqrs.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscribe@googlegroups.com.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

[Rickard Öberg]

YES!