Vinz

Booking Bus Kata

Մι∩z•thedev · Follow Published in Coding · 6 min read · 1 day ago __ 👏65k 💬321 🔖 ⤴️ __

This is an exploratory C# solution.

It’s on my github there: https://github.com/viiinzzz/CQRSBookingKata

Feel free to fork, I appreciate you drop me a word mailto:vinz.thedev@gmail.com for your valuable comments about the topic, I’m still learning, I’ll always be learning. Thanks for your support and your good karma ;-)

It started with a minimal kata session @Arolla but since I had time I extended it a bit for fun and pleasure.

I intended to explore architecture patterns a bit more advanced than those I used so far : Enterprise Bus Messaging and Command Query Responsibility Segregation

I took Hotel Booking for the exercise. The goal was not to produce a production grade solution ready for cloud provisioning nor to implement thoroughly the business logic. My goal was to consider the modelling requirements in such an architecture and to cast light on the prominent matters and advantages.

Production Enterprise Bus Messaging shall ultimately rely on commercial grade services such as Azure Service Bus, NServiceBus, RabbitMQ, MassTransit, Kafka, Amazon SQS…

Using Bus Messaging best allows achieving Domain Driven Design by ensuring cohesive logics stay together, speak their ubiquitous language, being decoupled from the other, owning their data, while being able to communicate and collaborate. We also see orchestrating patterns coming on top.

It is very satisfactory to grow an onion-like architecture, business logics, infrastructure, application. It gives confidence to be able to extend, modernise, replace parts with best control of entanglement, hence time/cost to deliver.

All this thanks to a bus, with its pub/sub mechanism, and serialization facility, over the web hence most probably talking http and json payloads. The communication requirements are various, it shall be reliable hence implement retry policies for unicast, broadcast and possibly multicast, it should be configurable hence offering immediate, scheduled, multiple, recurrent, coalescing deliveries.

One word about the asymmetrical read/write data usage. Why would it be ? Specifically sales are seasonal and subject to peaks. Many high bandwidth public searches (R) and fewer transformation (W). Restricted low bandwidth areas (R/W). The idea is to have specific services called query/command, and specific persistence. This way each channel can be scaled independently. Specific database/technology/caching shall also be used. Of course it implies additional synchronisation mechanism but here again the bus architecture will appreciably ease it.

Once the DDD/Bus architecture is laid down, it becomes pretty obvious hosting and scaling can easily be reached by adopting a few more microservices practices. It leads to Infrastructure as a Service, container, and container orchestration technologies, such as docker that recently paved the way for easy cloud formation thanks to powerful CLI commands. Docker is a serious option to consider to reach cloud agnosticism.

Nevertheless, one easily understand the tradeoff for such an agile architecture may be new challenges to cope with, like observability, end-to-end debugging. So to guard against complex bugs linked to distributed services, it is therefore important to ensure a good code quality with TDD and a CI/CD, and to provision also a clever central log aggregator.

Another challenge is to correctly tune orchestration over the bus, essentially complex operations, like distributed transactions, SAGA patterns will imply many async steps. The overall delay will be significantly greater than in a monolithic single database archi. That may be acceptable or not. Batch processing may limit overhead but increase even more latency. The important thing is to clearly identify the time requirement and to locate all the needed data or at least a good enough copy locally for a domain to process fast enough.

That’s it for this article. I envision this bus architecture for medium to large corporate mission where several dev teams may work in parallel for the various departments they deliver functionalities to. The bus would mimic closely what happen in the real world. An architecture to help real workers. An architecture to help company growth. An architecture to serve happy customers !