Architecture Weekly #144 - 11th September 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:
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:
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:
Check also more about Step Functions and their capabilities in Yan Cui's article:
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:
If you’re in the .NET space, check an article written by João Antunes:
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:
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
Oskar Dudycz - My journey from Aggregates to Functional Composition
Virtual DDD - Fireside chat: Orchestration and choreography with Laila Bougria & Udi Dahan
Colm MacCárthaigh - Workload isolation using shuffle-sharding
Kevin Hoffman - Documentation-First Event Sourcing with Concordance, wasmCloud, and Event Catalog
DevOps
Frontend
AI
Microsoft - Microsoft announces new Copilot Copyright Commitment for customers
Jessica Kerr - A Developer’s Starting Point for Integrating with LLMs
Azure
AWS
Java
JavaScript
.NET
João Antunes - Observing .NET microservices with OpenTelemetry - logs, traces and metrics
Jimmy Bogard - Tales from the .NET Migration Trenches - Empty Proxy
Rust
Product Design
Coding Life
Management
Harward Business Review - How to Build a Blameless Work Culture
Dave Farley - My Response To The NONSENSE McKinsey Article On Developer Productivity
Kent Beck - Measuring developer productivity? A response to McKinsey, Part 2
Gergely Orosz - Measuring developer productivity? A response to McKinsey 2