Immutability in Message Types

In just about every custom I've worked with, eventually the topic of immutability in messages comes up. Messages are immutable in concept, that is, we shouldn't change them (except in the case of document messages). Since messages are generally immutable in concept, why not make them immutable in our applications dealing with the messages themselves? Immutabilty has a number of benefits, ask Mark Seemann laid out in a discussion question [Read More]

Building Messaging Endpoints in Azure: A Generic Host

Posts in this series: Evaluating the Landscape A Generic Host In the last post, we looked at the many ways we can consume messages in Azure as a message endpoint. Unfortunately, there's not an easy answer. We don't have a simple, PaaS solution to a background service. We basically have some very bare serverless options, some shimmed options, and IaaS options through containers. Regardless of how we might want to [Read More]

Message Naming Conventions

One of the first design decisions teams starting with messaging are presented with are - what the heck do we name these things? When building out request/response types for typical API/web applications, I name the responses usually after the resource they represent, or the route, or controller/action. There's something already "around" my message that tells me what to name it. Durable messages are a bit different - [Read More]

Building Messaging Endpoints in Azure - Evaluating the Landscape

Posts in this series: Evaluating the Landscape A Generic Host When looking at moving traditional on-prem solutions to the cloud, I try as much as possible to avoid any kind of lift-and-shift strategy and instead leverage as many platform-as-a-service (PaaS) offerings as possible. Since our systems mainly consist of web applications backed by some sort of database, it's often a fairly straightforward transition. Web applications become hosted as Azure App [Read More]