What are some strategies for combining Event Sourcing with non-ES parts?

[Justin Workman]

I'm working through some ideas for migrating a legacy application to a DDD and Event Sourcing architecture, as a personal learning exercise.

I've heard in talks and articles that it's an anti-pattern to make an entire domain or application event sourced, and that care should be taken to only use event sourcing for parts that make sense or benefit from it in some way. In going through my legacy application, I can identify parts of the domain that an Event Sourcing architecture would bring value to modelling, and I'm also seeing other parts that don't seem to be a good fit for event sourcing.

The domain is related to online ecommerce, so things like cart events seem to naturally fit with ES. Payment transactions seem to naturally fit with ES.

I came across something that I'm not sure about. The legacy system keeps track of payment gateway credentials (adapter type for each gateway, API login keys to interact with the gateway service) and relate that to the tenant's configuration. On one hand, this appears to be something I don't want to be event sourced, because storing the API keys should not be part of a permanent, immutable log, and doesn't need to be anyways since for each tenant in our domain we either have a working set of credentials or we don't (it doesn't matter to our domain how that changes over time, as it's not even part of the core domain).

If I use event sourced aggregates for the core domain modelling and also for payment transaction-related business processes, how should I go about modelling it so that parts of it are event sourced and parts of it aren't?

The only thing I can think of is:

1. When payment gateway credentials are configured, instead of generating events, store the credentials in a key/value store, keyed on some aggregate's ID so it can be referenced
2. When a command to process a payment is executed, it requires the gateway credentials, so it looks it up by an aggregate ID as the key and decrypts it, then proceeds
3. When the aggregate responsible for being associated with the stored secrets is deleted or archived (a domain event, not a hard delete), an event handler will delete the stored credentials (by deleting the encryption key, or hard deleting the data, or whatever it has to do)

My questions are, is this the recommended approach to handling storing secrets outside of the event store, and is there a better way to think about combining parts of a system that are non-ES and parts that are, whether or not they are related to secrets? Another example that comes up a lot is user authentication - the recommendation being that it usually doesn't need to be event sourced anyways. So what are some strategies for doing some of both?

If the answers are as simple as linking to existing articles or threads I missed in my search, that is appreciated too.

Thanks in advance :-)

[Ben Kloosterman]

I think Cart / Categories are better as a NoSQL blob .. eg Redis / CosmosDB 

Checkout and transaction yes if you have complex logic. 

I start with the NON ES part of the system eg all the CRUD / master /reference / security data stuff. These are in different BCs  until you have logic. 
Then we introduced 1 aggregate - that's all .. but it is complex and business critical and provides a gradual introduction for other team members.

We found in the BC with an aggregate that there were a few cases that may become aggregates but I wrote them straight to the read model ( on a special stream ) with a string Name as the Id  , they maybe come Aggregates later if there is logic to justify it ( for now the only logic on them is create , rename and delete) so there is no Aggregate/ AR  the handler just writes to the stream  .

I would make the gateway an interface and just control the flow with ES , the password / communication etc should not be ES eg use a CRUD secure source Azure Keyvault / Aws secret manager / encrypted file .  An OrderProcessing aggregate would talk to an IGateway interface since its an external service  .  

KISS grow ES where needed . 

Ben

[Justin Workman]

Thanks Ben, I think that helps

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/0hcJZXtwS6E/unsubscribe.
To unsubscribe from this group and all its topics, 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.

--

Justin Workman

xta...@gmail.com