Immutability the self-imposed architectural constraint that data cannot be modified or deleted solves many of the technical problems of distributed systems... It prevents duplication; if you receive the same immutable message twice, you can see that you've already stored it. And it solves synchronization; two copies of the same immutable record are always exactly the same.
What would happen if we took immutability seriously?
Immutability -- the self-imposed architectural constraint that data cannot be modified or deleted -- solves many of the technical problems of distributed systems. It prevents duplication; if you receive the same immutable message twice, you can see that you've already stored it. And it solves synchronization; two copies of the same immutable record are always exactly the same.
Moreover, immutability solves many business problems as well. Immutable documents capture the intent of each collaborating party. They preserve the history of that collaboration. And they enable future business processes that we cannot immediately predict.
Some architectural patterns give a nod to immutability: model-view-update, and reactive programming for example. But what if we really took it seriously? What would an immutable architecture really look like?
I'll show you what it looks like. Whether you are building an immutable architecture for Web, mobile, or distributed systems, the modeling tools and patterns are the same. Learn how to implement immutability in a SQL database. See how immutability affects an API. And extend immutability across service boundaries via messages.
Together we will build an immutable architecture in .NET, persist data in SQL Server, and synchronize apps across a service bus. The example is open source, and based on real-world systems. Those systems have benefited from immutability to solve technical and business problems. Come see how you can do the same.
Recorded at Tulsa .NET User Group.
