Hosting is a Detail

January 30, 2020    Clean Architecture

Hosting is a detail

Last summer, we read Clean Architecture by Bob Martin as a book club at Omnitech. We all learned a lot. I even co-presented at SD Code Camp about Clean Architecture with John Townsend.

Uncle Bob showed us in his book that we need to isolate our Critical Business Rule Code from our Application Rule Code. Then we need to create another layer to isolate from the details such as the database, devices, web, UI and external interfaces. See his blog post for more details. We do this to isolate and reduce change. Changing the database shouldn’t change our “entities” that deal with business rules (example calculating interest for a loan).

Hosting is a detail. We don’t want to have to change our code if we change where we host our code.

I’m thinking about APIs or web apps. More specifically, we have 30+ .Net Framework and .Net Core Apis that have been created over the last 4 years.

Service Fabric (SF) Coupling - a story

I’ve been working with a team now for a year and a half. I was told that about 3 years ago a former team mate went to a conference and got excited about microservices. He learned about Service Fabric as well. He brought this back and the team decided to use Service Fabric to host their Asp.Net MVC APIs (HTTP endpoints) that would help them create a “Platform API”.

Fast-forward a few years and there are about 30 API projects running in SF. This is pretty cool! However, there are a multitude of problems that have come up with developing on SF and deploying it. With that many projects, F5 to debug doesn’t work well. Developers have to publish to local SF, then attach to the process to get debugging to work. This is not fun and costs time. Ops was having to run handmade deploy/update PowerShell scripts (which works well) and configuration is always interesting.

Some people started saying that we should just host the Apis in IIS or something else.

The problem is that the projects were created from the SF template and are completely tied to running inside of SF :-(.

The solution is to treat SF (and IIS/Kubernetes (K8s)) as a detail and not couple ourselves to it. All of the new APIs are now .Net Core using a Visual Studio template we’ve created. These projects bring joy into our lives with fast feedback and ease of use (see the 1st ideal in the Unicorn Project book (read it!)). It’s really great to set as startup project and hit F5 or dotnet run in a command line. The console output is helpful. We also got Open API aka Swagger working. Now we just need to updated all those old .Net Framework Apis (or at least decouple from SF).

Once all that is done, we will have the freedom to host where we want to. IIS would be easy. I’d personally like to put these into containers (which is super easy with Visual Studio) and use K8s (see my introduction to K8s article).

Do not tie to your hosting mechanism

The lesson

Keep your hosting decoupled, so you can move when a new or better solution is available.

.Net Core 3+ Worker Service

I highly recommend Steve Smith’s Clean Architecture Worker Service template. You can watch him build it from his Twitch recording.

I also recommend his Weekly Dev Tips podcast.



comments powered by Disqus

Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!

Support me and download Brave!

Use Brave