Image for post
Image for post

Test Driven Development

This is one of the most common test approaches. We implement our code based on unit tests. Each feature of your application should have a unit test designed before its implementation. The first time you run this test will fail. You finish your development when your test pass. We should follow the RGR development cycle.

Red, Green, Refactor


Image for post
Image for post

More and more we want automatic things. The operating processes that are always the same can be done autonomously following a set of steps. In the not too distant past, every time we want to deploy an application we build and copy those generated files to the server. So we need to have remote access to a server machine, we need to know which files need to be copied, where we should put them, and which other multiple services must be restarted. I’m tired of just describing this process.

The CI/CD principle, which means Continuous Integration and Continuous Delivery or…


Image for post
Image for post

This is a behavioral pattern that allows defining multiple strategies to resolve a problem. You can change the strategy that will be applied. Imagine your GPS, you can choose between multiple types of routes to arrive at your destiny. The fastest, the beautiful, the most economic, etc. These are a few examples of strategies that were defined in your GPS. Accordingly to your choice, the system will generate the route. The following image shows a possible organization in your solution.


Image for post
Image for post

It’s very common to have complex objects in our solutions. Objects that have multiple fields and each field is difficult to build. Who is familiar with this type of object? Everyone, I guess. Sometimes we have gigantic constructors to create an object. Let’s see an example:

public class Order
{
public Buyer Buyer { get; set; }
public Seller Seller { get; set; }
public Product Product { get; set; }
public double Price { get; set; }
(...)
public Order(Buyer buyer, Seller seller, Product product, double price, (...)) { Buyer = buyer; Seller = seller; Product = product…


Image for post
Image for post
Photo by K8 on Unsplash

One of the first things that you must define when starting a new solution, is the architecture that you will implement. Where the interfaces will be? Where your implementations should be made? Where you should place your HTML pages? These are some questions that are answered by the chosen architecture.

There are multiple options to use depending on your type of solution. Let’s imagine an example of a Web Application that reads and writes data from a database.

Three Layer Architecture

This is one of the most used architectures. It’s quite simple and distributes the responsibilities for 3 layers.


Image for post
Image for post
Photo by Todd Quackenbush on Unsplash

Nowadays these types of tools are increasingly more used because of the necessity to integrate multiple systems and applications. The cloud providers were also very important for the popularization of these types of tools. They have their own services to provide these books and hooks. The second ones are increasing their popularity due to the variety of applications and websites that provide support for them.

Runbook

It is a simple tool to automate your current operations. A runbook is a set of predefined procedures that can be defined in a Powershell script.


Image for post
Image for post

Nowadays, the creation of APIs is a very common solution when we want to make some features of our system available for other components. Since that, we can put an API as a public component and allow you to use it. The thing is that if you want to make some requests in your backend you must create an HTTP client in order to do the necessary requests.

Why is it good to provide a client library to your API?

That’s the main question that you want to have the right answer. It helps you to ignore some operations when you are developing a service because it avoids you from reinventing the…


Image for post
Image for post
Photo by Rosie Steggles on Unsplash

Left or right? You always have more than the visible options. Sometimes you need to convert some objects to another type. For instance, when you want to map a domain entity to its DTO (Data Transfer Object). Imagine that you have 30 domain entities and another 30 DTO entities, one for each domain entity. You will have a method for each type of entity to convert those objects to its DTO. This would be the first option that I would think.

What if we would have a way to automatically do this conversion?

It would be great, right? Yes. I present you the Implicit and Explicit operators for C#. Their objective is…


Image for post
Image for post

This is one of the most used and recommended patterns to apply in an application that works with any type of database. It provides a simple way to create a standard for your CRUD operations. If you like generics, you will love this pattern.

Why is it so good?

Because centralizes all the basic operations regarding an entity in one main class. Without this approach, we would have multiple classes with the same logic but for a different entity.

The following code block shows the main interface:

public interface IRepository<TEntity> { TEntity Find(params object[] keyValues); IEnumerable<TEntity> FindAll(); void Insert(TEntity entity); void Update(TEntity entity); void Delete(TEntity…


Image for post
Image for post

This pattern is focused on changes in objects. As Martin Fowler said, this unit keeps a list of changed objects in a transaction context. Also manages the write operation and deal with the concurrency problems. We can look at this as a context, session, or object which follows all the changes on data models during a transaction.

Architecture Overview

Tiago Martins

Just another programmer with some ideas.

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