Learning on the Job

As your software system begins to grow and become a successful, you may find yourself at a place where you will want to monetize your software by allowing other companies to use it. One such design that will come in handy is called the Multi-Tenant design, and it allows you to license your software to other companies, allowing them to use your software system for through some contract. You manage the system, and they are merely an entity within it, a tenant. Source At its core, a multi-tenant design is driven by the idea that each tenant contains an identifier, which is then passed through with each request or action. By including this information, the system will know what behavior or data set to pull from. Traditionally the tenant identifier is GUID  that is transferred through HTTP requests as a HTTP header, x-tenant-id . The value is then kept within the thread context, and used to determine the configuration of a request, as well as the data it can access. Data should ei

The point behind a presentation of Visualizing Software Architecture , by Simon Brown, was that we need to standardize the way software developers communicate with each other in respect to our discussions of software architecture. As part of Simon's consultation, one exercise he gave to software architects was a simple task to white board the architecture of a software system. The results he received varied immensely, and there was never a defacto standard format that he received from this exercise. When inspecting the feedback from the participants, the general answer was that it was easy to come up with the design, but difficult to properly put their ideas onto paper, or white board in this case. White Board Example, c4model.com Simon sought to start a movement by defining a set of organizational rules to help us describe our software architecture with a set of standard terminologies. His work has let to C4 Model , which stands for C ontext, C ontainers, C omponents,

A part of the  Template WebAPI  series. Request validation can be a powerful tool for enforcing correct usage of your service. By setting up requirements for usage beforehand, you can prevent errors from occurring within your service that may create side effects. For our implementation, we'll be using FluentValidation , a library for strongly-typed validation rules. In this post, we'll go over: Installing FluentValidation Create a Validator Create a Filter Integrate with WebApi 1. Installing FluentValidation To install .NET Core FluentValidation, install the package: FluentValidation.AspNetCore 2. Creating a Validator A validator is a class that you create in order to define the rules for how you should validate your object. We define a CreateCustomerRequest which contains some basic properties. Then we define our validation rules by creating an inner class Validator. Going with this inner class instead of a separate file is to group like code together, redu

A part of the  Template WebAPI  series. One design constraint that I wanted to enforce on the application is that the idea of app settings should stay in the within the API layer. But we still need a mechanism for transferring configurations form the API down to the various implementations. The best design I've come across is to define your configuration dependencies through interfaces, which you can type against your configuration file. Take a look at MongoConnector.cs, where we have to give it a connection string and database name in order to instantiate it. We wrap the configuration in the file MongoConfig. Then when we want to setup the service, we can define the configuration by referring to our app settings. Now we have define a configuration for an external service, without having to pass around our complete AppSettings file, and the configuration is abstracted away from the external services. Full configuration can be found on Github .

Short post today, mostly just wanted to how to setup RabbitMQ for local development. Refer back to my previous post to learn more about RabbitMQ. Prerequisite Docker For complete guide reference, check out the Docker Hub Website for RabbitMQ . Why use Docker? Before starting my current job at iHerb, I would go straight for the Windows installation (my development environment) for all of my development tools needs. It was straight forward and "just worked" a lot of the time. What I've begun to realize experimenting with all these different tooling and services is that things can get a bit cluttered, you will have a bunch of supporting systems that need to be run - caches, queues, databases and it can be a hassle to manage them through window services and executables. Additionally some of these require additional dependencies outside of the executable itself, which prompts you to install even more tooling. The great thing about docker is that it defi

A part of the Template WebAPI series. Solution Structure The first distinction that I want to make about the project is the solution structure and how to organize your code. As of the the date of this post, the package structure is as so: project src clients template.Api core template.Domain template.Application template.Persistence test project This folder is used to store any project assets that may need to be edited by the developer, such as ignore files or deployment files (such as docker). Files that generally don't get touched by developers can stay outside of the solution. src This folder contains all of the code used to execute the running application(s). clients Clients are the executable running projects that combine integrate the software into a single application that will be used by consumers. There may be many clients, such as support systems such as cache services, running jobs, or other systems that support your main application.

The basis of my current understanding of architecture comes from the brilliant mind of Robert C. Martin (Uncle Bob). You can find the original post through his blog , which I strongly encourage you to read. In this post I'll try to summarize some of the key points I've understood from his post. Clean Architecture Source Clean architecture is a design used to emphasize the structure and relation of your various code components to promote the idea of Dependency Rule , such that "source code dependencies only point inwards" . Clean architecture is able to promote this by defining that your software system consists of various layers , that can be organized in such a way that the layers point in one direction, and a dependency graph will not have circular reference. The reason this is important is because it allows you to keep closely code related, and increase clarity of how components fit into your system. Explaining the Layers We can really separate out this

Working in the .NET environment, you will quickly become familiar with Web APIs, which is the web server solution Microsoft provides as part of the .NET ecosystem. Building many APIs over the years, I've started to gains opinions about what I like and don't like about how systems are built. I'm happy to showcase my recent work, Core Template, which I've been refining and tinkering with to get it just the way I like it. The Core Template is an example micro service that one would build using .NET Core designed with Clean Architecture in mind. The goals of this template: Be easy to follow! Following the Dependency Rule - Source code dependencies should only point outward Work with pure entities, rather than depend on database objects Organize classes to be easy to find, and make sense Without further ado, please check it out on Github .  I will follow up with articles that explain my different design choices, and will continually keep it up to date as

Liveness and Readiness When designing a distributed system, one of the metrics you'll probably need to track is how healthy are your systems. In a monolith system, it is easy to determine when your system is down because a larger system will be unable to service requests, leading to immediate feedback for your errors. Moving to a micro service architecture splits that problem into many sub problems, as now you have many different systems that could possibly go down, be under more load than others, and generally be smaller such that you want to be able to scale small instances rather than rely on few large instances. This is where we introduce the concept of health checking instances, such that they can report metrics back to the infrastructure so that it can decide what it needs to do for optimal performance. Two common health checks are: Readiness and Liveness Readiness Readiness is that status that the application is in a state that it can begin servicing requests. Dur