HARDCODE

      When designing a system, you should not limit yourself with using only one type of databases. Some business needs might require having a more flexible sort of databases like NoSQL / Document databases.  One of these databases is Elasticsearch ,   which is a topic that I have talked about in a previous post that you should definitely check out. However, if you use more than one database for your system, making sure that all your databases are in sync is crucial . How It Started 🚩 As I said in my previous post . The other sort of problems that we have faced while working on the microservices project is data inconsistency. To explain this problem I have to tell you why the system needed an Elasticsearch index. In microservices projects you usually have more than one database, one for each service/domain. The client-side needed an aggregated document of the data from all the databases. Which in microservices is called The Aggregate Root ,   and that is ...

     People always want the newest things. The more trendy something is, the more it appeals to most people. Same applies to technology. Adding the word microservices to the CV can help it shine a little bit. These are some of the thoughts I was having while I was 2 hours deep into debugging an issue in a project that involved .Net, Kafka, SignalR, React js, Elasticsearch, ECS, MediatR and more. Beware of Microservices  ⚠️ What I'm about to share is a cautionary tale for people who are on the verge of shifting their solution into a microservices architecture. Before you start implementing such an architecture, please read carefully the decisions that others have made along with their consequences so that you can see for yourself the outcome of each design decision instead of falling for the same mistakes. Before anything : The case study that I’m about to discuss might have had its problems. However, the people who made the design decisions are very good software e...

   In the software engineering industry, the term CQRS is used quite often. It describes a pattern which allows you to handle services in your system in a vertical manner. It gives you the ability to free yourself from any other service in the same domain and allows you to focus on the service that you wish to implement. I know that there are hundreds of other resources that can explain the CQRS pattern better in terms of definition and philosophy. However, in this article I'm going to explain it in another way, a rather practical way. Imagine you have an entity named Customer . Normally if we follow clean architecture , we will have a single horizontally scaled service called CustomerService . In this CustomerService there are all types of services that perform different operations on this entity. However not all services need to operate on the whole entity model. This is why Data Transfer Objects exist. Data Transfer Objects (DTOs) are a simplified versions of entity mode...

 In my previous post  Download Image API Using MediatR Vertical Architecture  I talked about how to use MediatR to perform commands or queries however I have not explained how to integrate a validator so that you can validate first then handle the request you receive. In this article I'm going to show you how to add a validator to your pipeline. A pipeline that in my case will only consists of two steps validation and handling. I will be using the same set-up as my previous post so if you're going to follow the next steps make sure you complete the example in my previous post linked above. Fluent Validation First step we need to add a very useful and popular library which will be the validator that holds all of the rules that the request should follow. It's an important library that provides validation rules (custom and out of the box) with readable members such as NotEmpty() , Must() , etc. Fluent Validation is not the only option you can also use Data Annotations howev...

As I mentioned in one of my previous posts, I will be showing you how to make an API that downloads an image to a local path.  But I will take this as an opportunity to show you an example of how to achieve that using vertical architecture with MediatR . One of the most common problems with clean architecture is that there usually is a service class for each domain entity that encapsulates all application logic regarding this entity.  Something that if you have applied on a larger scale project with a little too much business logic you would find that the class got too big, and maintainability becomes a little more difficult by each added logic.  Also, data transfer objects ( DTO ) start to have weirder names because you can't have a one-size-fits-all model that accommodate the growing logic in your service class.  (eg. CustomerDTO.cs, LoyalCustomerDTO.cs, CustomerLightWeightDTO.cs) Not to mention of course pull requests and merging codes become a living nightmare....