Discover more from Architecture Weekly

Weekly Software Architecture resources to boost your knowledge and developer skills.

Over 3,000 subscribers

Architecture Weekly #144 - 11th September 2023

Sep 11, 2023

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Welcome to the new week!

I didn't plan to have sponsors for Architecture Weekly. I wanted to focus on providing a set of resources only biased by my experience and perspective. I focused on building a paid community for fellow architects and tech leaders to exchange experience. And I still do, but...

I'm happy to announce that Particular Software will sponsor the next set of releases. Why did I change my mind? Actually, I didn't.

I have known folks from Particular for a long time; I've been following and also publishing resources from Udi Dahan, Laïla Bougriâ, Daniel Marbach, Mauro Servienti, Szymon Pobiega and others. I also learned from them. Knowing them in person, I know we have a similarly pragmatic vision of building the software. Plus, I value their works like NServiceBus.

What persuaded me is that they didn't try to push me to publish their works or add hidden advertisements or praises for their works. They want to build synergy with the community and let people decide on their own whether to try their products. If you want, click the link at the top.

It's also a step for me to make my work around Architecture Weekly more sustainable to keep it going and provide even more content here.

Speaking about new Architecture Weekly content.

We’ll have a new webinar for paid subscribers this week. Funnily enough, it’ll be the 13th webinar on the 13th of September. Yet, not on the 13th hour, but 18 CEST.

This time, a special guest Yves Goeleven, will show us Fantastic 9. What’s that? Let’s give Yves to explain it:

There are thousands of design patterns to choose from, but in reality I believe we only need 9 design patterns to build any system imaginable. Why only 9? And which ones? Join me in this session and I'll introduce to these Fantastic 9...

When I saw this talk live at Techorama my reaction was:

I really wanted to see it again, and as I haven’t found the recording of it anywhere, I’m thrilled that Yves agreed to join our community and give it to us!

Yves is an independent software architect, founder of clubmanagement.io and messagehandler.net. He is specialized in the design of distributed software systems using Progressive Web Applications, Event Driven Architecture, Domain Driven Design, Event Sourcing, messaging, and Microsoft Azure.

I think that the Fantastic adjective is not exaggerated. Those 9 messaging patterns are a condensed way to translate the conceptual model into actionable architecture.

Subscribe to become a paid subscriber, and join us live!

You’ll also get immediate access to all past webinars.

Messaging Orchestration and choreography was also a topic of the Virtual DDD community meetup:

Virtual DDD - Fireside chat: Orchestration and choreography with Laïla Bougriâ & Udi Dahan

It’s one of the most “it depends” one can imagine, and you can hear that in Laïla’s and Udi’s answers. Still, I value when the “it depends” answer is followed by “on what”. The fireside chat option is a decent format to get personal heuristics from the guests’ experience. It's always good to start with the foundational knowledge to keep pace with the Q&A.

Besides the introduction that Laïla did at the beginning, you can check my articles:

I liked how the hard but foundational topic of the messaging systems was tackled, e.g., whether there is a difference between microservices and monolith, documenting the flows, troubleshooting, etc.

Check also a concise article by Dariusz Gafka, where he explains why proper messaging is important and why you should start with design and not go YOLO:

Dariusz Gafka - YOLO Message-Driven Architecture

One of the ways to handle choreography in practice are AWS Step Functions. They bring a simplified, declarative way of handling processes in a centralised way. Such a way is useful if you want to have more control and a clear view of the process. Step functions nicely integrate with other AWS tooling, and it’s a decent way of dealing with it.

However, their con is that sometimes they’re too magical, and if your process is too complex, they may be hard to maintain.

Still, AWS is adding more and more to make it a seamless experience. Recently, they added more features to enhance error handling:

AWS - AWS Step Functions launches enhanced error handling

Check also more about Step Functions and their capabilities in Yan Cui's article:

Yan Cui - Step Functions: combine Standard and Express workflows for fun & profit

One of the most challenging aspects of understanding the message flow is how to document it.

EventStorming is a decent way to start, but it’s hard to maintain, as its main purpose (as the name suggests) is to brainstorm and facilitate collaboration between business people and us tech folks.

Event Modeling, in theory, is more aimed to be kept up to date, as we have more organised slices.

Yet, both are lacking code-first tooling, that’s important for maintenance reasons.

Such a tool should not only be used for visualisation, but also for analysing the relationships, etc. We don’t yet have popular tool "like Swagger, but for messaging”, we have nice tries like EventCatalog. Read more in a nice introduction:

Kevin Hoffman - Documentation-First Event Sourcing with Concordance, wasmCloud, and Event Catalog

If you’re in the .NET space, check an article written by João Antunes:

João Antunes - Observing .NET microservices with OpenTelemetry - logs, traces and metrics

He greatly shows how to set up the tracing, metrics and logs for our applications, including messaging pipelines. We have OpenTelemetry standard, but it’s quite easy to get lost even with it. This article is a good, actionable piece backed by good personal experience.

I was asked this week on why do I prefer immutable data and functions over Aggregates in my works.

I decided to share an extended answer as a blog article to show my journey to modelling business logic. I think that it’s worth knowing the background and motivations to get the full context. Read more:

Oskar Dudycz - My journey from Aggregates to Functional Composition

Check also other links!
Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture Weekly

Discover more from Architecture Weekly

Architecture Weekly #144 - 11th September 2023

Architecture

DevOps

Frontend

AI

Azure

AWS

Java

JavaScript

.NET

Rust

Product Design

Coding Life

Management

Security