Roundup #49: .NET Core 3 Preview 7, MasterMemory, Alternatives to Microsoft.FeatureManagement, Monolith Decomposition Patterns

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.

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Follow @CodeOpinion on Twitter

.NET Core 3.0 Preview 7

Today, we are announcing .NET Core 3.0 Preview 7. We’ve transitioned from creating new features to polishing the release. Expect a singular focus on quality for the remaining preview releases.


MasterMemory — Embedded Typed Readonly In-Memory Document Database for .NET Core and Unity

As a new open-source library, we present to you a read-only in-memory database that focuses on management use of master data.

We made it from our experience in game development up until now with an emphasis on the three points of “Saving memory (also because it is called in-memory, it pays attention to memory usage)”; “High-speed database loading (when it takes a long time to build, it will have a major effect on a game’s startup speed)”; and “High-speed search (similar queries as dictionary lookup.)” 


Alternatives to Microsoft.FeatureManagement

In this series I’ve been looking at the Microsoft.FeatureManagement library (which is now open source on GitHub 🎉). This provides a thin layer over the .NET Core configuration system for adding feature flags to your application. But this library is new, and the feature flag concept is not – so what were people using previously?


Monolith Decomposition Patterns – Sam Newman

Patterns to help you incrementally migrate from a monolith to microservices.

Big Bang rebuilds of systems is so 20th century. With our users expecting new functionality to be shipped ever more frequently than before, we no longer have the luxury of a complete system rebuild. In fact, a Big Bang migration of a Monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk. We want to ship features, but we also want to change our architecture – and many of us want to be able to break down existing systems into microservice architectures. But how do you do this while still shipping features?

In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll even cover off patterns that can work to migrate functionality out of systems you can’t change, making them useful when working with very old systems or vendor products. We’ll look at the use of stranger patterns, change data capture, database decomposition and more.


Follow @CodeOpinion on Twitter

Software Architecture & Design

Get all my latest YouTube Vidoes and Blog Posts on Software Architecture & Design

Leave a Reply

Your email address will not be published. Required fields are marked *