Divide and Conquer or How to achieve bottom-up behavior in code

Hey everyone. I’d like to share here some of my experience and approach as to code structure and different ways of organizing the code flow during app bootstrapping process. My experience lies mostly in .NET/C# and Node/Typescript world but the principles should be easily applicable elsewhere provided the infrastructure is in place.

Let’s concentrate on one specific case which is the .NET 6 apps (console, web, desktop — doesn’t really matter). One of the most common issues about organizing the app bootstrapping code is that it could become somewhat cluttered even in case of microservices and thus hard to follow and maintain. The issue becomes even more complex as the number of microservices grows and they start to reuse some of the functionality via common modules/packages. Moreover, imagine you have numerous implementations of the same interface and you’d like to juggle between them easily and persist your changes without introducing too much source control noise. If any of the issues sounds familiar, let’s move on :)

The idea here is very simple — keep functional blocks (modules )small with high degree of encapsulation and cohesion (preserving the SRP) and make them as composable and extensible as possible. On top of this, encapsulate the desired bootstrapping flow inside a single entity to increase SRP even further. This leads us to the concept of Bootstrapper.

Base bootstrapper for IServiceCollection-based apps (AspNetCore, etc.)

As you can see here this tiny piece of code actually defines few things:
1. Extensibility — the core functionality can be extended in any way by using middlewares (which are merely fluent extension methods invoked in lazy manner)
2. IoC/DI awareness — the focal point for registration of required services to be injected during app’s lifecycle
3. Composition and Modularity — this functionality is provided by the Solid.Bootstrapping.BootstrapperBase class. If you’re interested in reading more about the way it works please refer to https://godrose.gitbook.io/solid-net-framework/bootstrapping

Using this approach actually does all the heavy lifting of discovery and composition of app’s modules, dependencies/services registration and much more. See the example below:

One of common ways of organizing code in DDD-oriented microservices

By using the composable and extensible bootstrapper approach we can achieve very static code of the bootstrapper itself thus preserving the OCP while putting all dynamic parts of code (services registration, etc.) into the dedicated classes (composition modules).

This is the mere amount of code needed to create the bootstrapper. The composition options definition is optional and is used here for optimizing assembly discovery and inspection/scanning part.
An example of specific dependencies to be registered into the DI Container (IServiceCollection in this case)

Employing this approach will allow true bottom-up architecture where all assemblies will register their internal dependencies without the knowledge leak into the startup’s one, allowing for more concise and maintainable code.

Hope you enjoyed this article. If you got any questions or comments feel free to contact me in the comments section of via mail (godrose@gmail.com) or on GitHub (godrose)

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

https://t.co/mh8bgNQPvj https://t.co/iKrlROU9s6

Testing with Threads

71.9 Celsius to Fahrenheit

Move all the zeroes to the end

Easy Lambda Optimization

AWS RDS and WordPress Integration

Install SFML 2.5.1 On Ubuntu 18.04 and CLion

Introducing MLH’s North American 2019 Hackathon Season!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gennady Verdel

Gennady Verdel

More from Medium

Changing the wheels while driving — our B2B Organisations refactoring

Stop Blaming Your Dev Teams for Production Incidents

Managing Technical Debt Is No Different Than Managing Health Debt

Performance appraisal vs. management

Sure.Pexitest.com Performance Management Grid