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.
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).
Keep your hosting decoupled, so you can move when a new or better solution is available.
I also recommend his Weekly Dev Tips podcast.
Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!