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

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.

.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.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

4+1 Architectural View Model

It’s incredibly difficult to describe a complex system, regardless if you are developing a monolith or (micro) services. Use cases, code organization/navigation, interactions between services, and deployment/infrastructure are just some of the aspects that comprise the architecture of an entire system.

Depending on your role as a stakeholder, your view of the system can be very different than another stakeholder.

This blog post is in a series. To catch up check out these other posts:

Context Matters

There are many different stakeholders related to a software system, which all have different perspectives. Project/Project Managers, Developers, System Engineers, End Users all view a system in completely different ways. They view the system based on their own context.

In order to describe a system, it would be useful to define all the different viewpoints and how the overall use cases of the system.

4+1 Architectural View Model

We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is a bit of everything.

The paper by Philippe Kruchten, Architectural Blueprints—The “4+1” View Model of Software Architecture, defines 4 concurrent views from the point of view of the various stakeholders.

4+1 Architecture View Model

I recommend reading the paper but for an incredibly simplified version of the views:

  • Logical View: The functionality. The service.
  • Process View: Communication between processes and/or services.
  • Physical View: Deployment of your services.
  • Development View: File/Folder Structure of your codebase. What you’re looking at in your IDE/Editor

The +1 comes in from the scenarios view which is what your end users actually care about. It’s the system functionality/capabilities. The scenarios view is what guides all the other views.

Service Boundaries

Where I think general guidance has fallen short when developing (micro)services is just because you’ve identified multiple logical views ( services), does not mean that each must have their own independent deployment (physical view) or git repo (development view).

To be clear, there are obvious benefits to having independent deployments, but there are many disadvantages as well. But it’s not a requirement.

As an example, in .NET, you could have a solution with various projects that represent different logical views. None of these projects reference each other, they are simply in the same solution. There may however be an ASP.NET Core project that hosts these projects as a single process.

Point being is that just because you have multiple services does not necessarily mean they need to be developed independently or deployed independently.

The four views are representations of the system depending on the context. They don’t need to map 1:1.

When not everything maps 1:1, that’s when it makes it a bit more challenging finding service boundaries. Focus on the scenarios.

Blog Series

More on all of these topics will be covered in greater length in other posts. If you have any questions or comments, please reach out to me in the comments section or on Twitter.

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #48: .NET Reunified, Performance in .NET Core 3, XAML Hot Reload, Blazor

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.

.NET Reunified: Microsoft’s Plans for .NET 5

When Microsoft announced .NET 5 at Microsoft Build 2019 in May, it marked an important step forward for developers working across desktop, Web, mobile, cloud and device platforms. In fact, .NET 5 is that rare platform update that unifies divergent frameworks, reduces code complexity and significantly advances cross-platform reach.


What’s new for performance in .NET Core and ASP.NET Core 3.0 – Ben Adams

One of the biggest advantages of using .NET Core (besides cross-platform support) is the drastic improvements in performance. Because the .NET Core team was able to make minor breaking changes in the runtime and Base Class Library (BCL), lots of stuff was implemented much more efficiently. In this session Ben will dive into the performance improvements in .NET Core in the 3.0 release: runtime changes, JIT changes, intrinsics and a deep dive into some of the improvements making it the best release yet!


Announcing XAML Hot Reload for Xamarin.Forms

Today at Xamarin Developer Summit, we announced XAML Hot Reload for Xamarin.Forms, which enables you to make changes to your XAML UI and see them reflected live, without requiring another build and deploy.

XAML Hot Reload for Xamarin.Forms speeds up your development and makes it easier to build, experiment, and iterate on your user interface. And this means that you no longer have to rebuild your app each time you tweak your UI – it instantly shows you your changes in your running app!


Blazor, a new framework for browser-based .NET apps – Steve Sanderson

Today, nearly all browser-based apps are written in JavaScript (or similar languages that transpile to it). That’s fine, but there’s no good reason to limit our industry to basically one language when so many powerful and mature alternate languages and programming platforms exist. Starting now, WebAssembly opens the floodgates to new choices, and one of the first realistic options may be .NET.

Blazor is a new experimental web UI framework from the ASP.NET team that aims to brings .NET applications into all browsers (including mobile) via WebAssembly. It allows you to build true full-stack .NET applications, sharing code across server and client, with no need for transpilation or plugins.

In this talk I’ll demonstrate what you can do with Blazor today and how it works on the underlying WebAssembly runtime behind the scenes. You’ll see its modern, component-based architecture (inspired by modern SPA frameworks) at work as we use it to build a responsive client-side UI. I’ll cover both basic and advanced scenarios using Blazor’s components, router, DI system, JavaScript interop, and more.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.