Press "Enter" to skip to content


Test Driven Development

TDD Workshop

TDD Cycle

TDD tells that a test case should be written first, then the code should be written.

TDD is a cyclical process and includes three stages: RED, GREEN, REAFTOR. In the RED stage, a test case is written and executed. The test case fails. In the GREEN stage, first code is written for the test case to pass. The code doesn’t need to be clean. The main goal is to write the simplest code for the test case to pass. The test case is run again. If the test is successful, the REFACTOR stage is started. At this stage, if the code can be refactored, it is done. The test case is run again. If the test case fails, the code is refactored. This cycle is continued until the code becomes desired.

What is Modular Monolith?

Traditional Monolith

Firstly, let’s talk about Traditional Monolith approach. This approach focuses on layers. It includes three layers, UI, Business and Data. All features in a project are vertically separated into these layers. Among those three layers, the business layer is the one that contains business logics of all features. Each feature knows business logic of other features, which is a fact we call tightly coupled.

Traditional Monolith

Developing Blockchain App – #2 Interaction with UI

In the previous post, we prepared the contract and wrote the test codes. In this post, we will make the contract interact with UI and call the functions defined in the contract. If you haven’t read the previous post, you can reach it from the following link.

Developing Blockchain App – #1 Create Smart Contract

This series of articles will consist of 3 parts. In these articles, we will develop a Dapp (decentralized application). It will be like Hands-on Labs. This article is about creating smart contracts.

Smart Contract ve Solidity

Smart Contracts are code parts that run in a blockchain network and store data. So it is a structure that contains both codes and data. Solidity is a programming language that enables us to write contracts.

ASP.NET Core Feature Management

Feature Management provides feature management in .NET Core applications. It allows the management and querying of the active / passive status of the features of the application. For example, you can ensure that a feature you have just developed is active in a certain date range. To give another example, you can ensure that a feature you have developed is active with a certain percentage. Like A/B testing.

Event Sourcing with ASP.NET Core – 02 Messaging

1. Introduction

Since this article is second part of the article below, I recommend you to read the following article before starting. We will continue with the sample project in the article below.

In the previous article, we made the example of Kanban Board. By creating a RESTful API, we wrote the create, assign, move and complete endpoints. We recorded the requests coming to these endpoints as an event in the Event Store. So we focused on the store part of the Event Store. In this article, we will focus on with the messaging part.

We will include the following endpoint in our RESTful API endpoints.

[GET] api/tasks/{id}

Event Sourcing with ASP.NET Core – 01 Store

1. Introduction

I recommend you to read the article below before applying this example tutorial.

In the article I have mentioned above, I had formed a sentence as follows.

There is a technology called “Event Store” in the .NET world for Event Sourcing. This technology offers solutions for “Aggregate” and “Projection”. In other words, in addition to providing the store where we can record the events, it also provides the “Messaging” and “Projection” services, which are necessary for us to record in “Query” databases.

In this article, we will deal with the store section of the Event Store. In other words, we will deal with the database feature where we can save events. In the next article, we will deal with the messaging part.

As an sample application, I chose the classic Kanban Board sample.

Our RESTful API endpoints will be as follows.

[POST] api/tasks/{id}/create
[PATCH] api/tasks/{id}/assign
[PATCH] api/tasks/{id}/move
[PATCH] api/tasks/{id}/complete

Couchbase GeoSearch with ASP.NET Core

The subject of this article will be about how to do “GeoSearch” by using Couchbase.

1. Installing the Couchbase

For this purpose, we create Couchbase cluster with the docker by running the command below.

docker run -d --name couchbase -p 8091-8094:8091-8094 -p 11210:11210 couchbase

When Couchbase is up, it will start broadcasting at the address below.


We create the cluster by clicking the “Setup New Cluster” button. We define the password as “123456”.

Create New Cluster
Create New Cluster

You can make adjustment according to your current memory status. You can turn off “Analytics”. We complete the cluster installation by clicking the “Save & Finish” button.

What is Event Sourcing?

Previously, our services would be as follows.

Application Services 01
Application Services 01

This service consisted of hundreds of lines of code. To get rid of this confusion, we split our services into two parts as “Command” and “Query” with CQRS. We performed our CRUD operations with “Command” services and our query operations with “Query” services. Two separate services appeared as follows.