How do you use Clean Architecture with a CQRS or event driven architecture?

[pescadorbob]

One of the challenges I've faced with Domain Driven Design systems on CQRS and event-driven microservices is how to write them with clean architecture or hexagonal architecture in mind. The challenge increases when you consider how events enable nearly limitless functional extensibility to the behavior. How does one go about writing the BDD tests at the unit level for something like that?

[PCreations]

What are you struggling with exactly ? Maybe this article will be useful for you : https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

[pescadorbob]

Whoah, that's quite the graphic! I'll take a look.
The challenge I'm having is that I'm used to pretty explicit and contained use cases, but the event driven architectures are so loosely coupled that many things might occur that aren't defined as part of the use case because there is no use case defined. I started asking all sorts of folks how they might write their tests for event driven or CQRS systems where elements of the use case are so distributed. Mostly I got shrugs. I got responses like, you don't test the whole use case. You test just the event handler. To me it felt much like you would get 1 to N events in one traditional use case that describes the behavior. I feel like I still want to test the choreography of the events though, like that would be their behavior, but I'm not sure how I would do that.

[valentinajemuovic]

@pescadorbob great question, the impact of architecture on the decomposition of use cases.

I think there wasn't a clear answer to these because all the diagrams for hexagonal and clean architecture are at the monolith level; the case of distributed systems was not covered there.... So that could explain the part "Mostly I got shrugs. "

So the following is how I currently see it. Let's say the use case in e-commerce is making an order, which could mean processing payments, reserving inventory, and sending an email notification.

1. In the case of a monolithic architecture, all this could be in just one use case handler. So the unit test covers the entire use case.
2. In the case of microservice architecture, we would split this across the microservices, i.e. we're effectively decomposing the use case behavior... So then when we do unit testing, we can only test a part of the use case behavior. But then how about the full use case behavior? (i.e. the behavior with the events). Well, in addition to the unit tests, we'd have 2e2 tests... But e2e tests are harder to setup, more fragile, so by using contract testing to minimize e2e tests. There's different opinions here, I personally would have an e2e test for the overall main happy path scenario (esp. for critical use cases), and the rest would be covered with unit and contract tests.

[pescadorbob]

Thanks Valentina for your thoughtful response. I've had some preliminary and most likely naïve thoughts about an approach somewhere between testing the event handler and an e2e test.
You mentioned that "in a monolithic architecture, all this could be in just one use case handler." This reminds me of a passage in Uncle Bob's book, "Clean Architecture" where he says:

"A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services. Later, as things change, it should allow for reversing that progression and sliding all the way back down into a monolith."

C., Martin Robert. Clean Architecture (Robert C. Martin Series) (p. 157). Pearson Education. Kindle Edition.

If this is true, it seems there is a possibility that I develop this as a monolith and the entire use case can be tested then as a monolith, even though I'm using EDA or CQRS.

E.g. what if I made the connectors for the communications bus by which they all communicate something that could have a test version that is swapped out for environment deployment, but for local use case tests, those message just ran in memory.

Couldn't I then create a code level API for the system in a way that allowed the system to be built and tested as a monolith, but deployed as a microservice?

[valentinajemuovic]

You're welcome, Brent. When it comes to Uncle Bob's sentence, it is true that we can start with a monolith and then go to microservices, esp. when it comes to testing.

Ok firstly, let day we have a monolith, and we have one use case, it's implemented in one handler.

We break up that monolith into a modular monolith. That use case isn't in one handler anymore, it's now possibly split into multiple handlers. Our same use case unit test can still cover the use case in-memory. Reason is even though we have a logical splitting, they're all still running physically in one process. So with the unit test we can traverse the whole use case.

Then we go from the modular monolith into microservices, each microservice is running in a physically separate process... This physical separation is the root cause of issues... Our unit test can no longer traverse the use case because the use case is executed across processes... Of course, we test a segment of the use case behavior in the bounds of the microservice and substitute test doubles for the MQ... So we can test segments of the use case via unit tests... But the whole use case can only be traversed with e2e tests...