Jan 28, 2022
Applied System Architecture
It’s time to apply our knowledge of system architecture (read first) to Astro Bookings. We will lean on the requirements and think about the problems of the users. Then we must introduce the technical constraints and provide scalable capabilities.
And of course, we’ll do it all by following standard patterns and choosing simple approaches.
📘 About the example
AstroBookings: Our pet-lab-sample-demo project is a solution for a fictitious space tourism company that wants a platform to offer rocket tickets and reservation of rooms in space hotels. You can follow the development progress by subscribing to my newsletter, or by reading the project wiki.
️3️⃣ Three-tier architecture
I use to default to this architecture because of the flexibility and separation of responsibilities it offers.
The Presentation Tier
I will create a web application balanced to the client-side for this particular case. A well-known front-end solution is to build an SPA.
The Application Tier
Following simple standards, we should offer an HTTP-based API guided on REST principles and constraints.
The Database Tier
Of course, we will store every piece of data in a dedicated relational database.
🔀 Event-based CQRS pattern
We have simple, but highly demanding, requirements for presenting travel information. On the other hand, there are complex logic and procedures when reserving or releasing bookings.
Therefore, it is a good candidate for treating queries and commands differently. And here shines the Command-Query Responsibility Segregation pattern.
⬅️ For the query side.
We will keep the API simple and make the queries fly using a dedicated document database. This way there will be no complex joins to execute on the database side. And no need to adapt schemas to the API. All goes smoothly from the store to the browser.
➡️ For processing commands.
Things get more complicated. At least, we should provide a service dedicated to processing the commands. This service will be responsible for storing information on a standard and reliable relational database with transaction capabilities.
🛄The time to wait
Some requirements involve calling external services, such as email systems and payment gateways. And above all, I am concerned that we have to interact a lot with various external APIs provided by our affiliated operators.
Of course, having two different data stores needs some kind of eventual consolidation.
🔂 The queue
Those jobs are inherently slower. Running all within the same process seems a bad option.
So, we need a mechanism to orchestrate the potentially lengthy tasks. And for this problem, we will use a simple pattern that allows us to store the pending calls without waiting for them to be executed: A message queue.
🗺️ Containers diagram
One picture worth a thousand words. I like to follow the C4 model for visualizing software architecture.
The c4 offers a diagram category for each abstraction level. At this step, we are at level 2, called Containers Diagram.
🧙♂️ Heads up, this has nothing related to deployment technologies. A container here is a runnable unit that executes code or stores data. For example a client app, a web server, or a database.
So here we have the graphical representation of our chosen architecture and below you will find a link to the textual definition and the full-size picture.
Containers Diagram · AstroBookings/.github Wiki · GitHub — github.com
Astro Bookings Community Development. Contribute to AstroBookings/.github development by creating an account on GitHub.
📡 What comes next?
We are digging deeper approaching our beloved technical job. Next time we can explore the more complex parts of the work ahead. Then inners of the Commands Service.
It is complex enough to be a candidate to apply another pattern, with the domain at its core. Enter the tactical Domain-Driven Design.
I hope you stay with us in the process, which will be updated as always in our newsletter and here in my Medium blog series
Learn, code, enjoy, repeat.
Alberto Basalo
