Murat Genc

1. Introduction: Definition and Use Cases of the Transactional Outbox Pattern The Transactional Outbox Pattern is a design model that enables reliable communication between microservices. This model allows a microservice to perform database operations and send messages outwards within the same transaction. As a result, either both operations succeed or both fail, ensuring data consistency. The key components of this model are an “Outbox” table and a “Publisher” service. When a transaction occurs, the microservice first performs a transaction in the database and then writes a message to the Outbox table within the same transaction.

Continue reading 

Once upon a time, there was a tree in a forest. This tree was a complex structure with leaves and branches. Each branch could have smaller branches and leaves on it. The tree worked as a whole, holding its branches and leaves together. This tree is an example of the Composite design pattern. The tree (Composite) contains two types of components: branches (also Composite) and leaves (Leaf). Both branches and leaves implement the same interface (Component) recognized by the tree.

Continue reading 

Once upon a time, there were two kingdoms. Despite being very close to each other, a wide and deep river was located between them. This river made it difficult for the kingdoms to interact with each other. To solve this situation, both kingdoms decided to build a bridge. This bridge became an interface that facilitated communication between the two kingdoms. However, the bridge had different structures and features on each side.

Continue reading 

The Anemic Domain Model is a software design pattern where most of the domain logic is found in services and data transfer objects, often obscuring functionality and behavior, and is typically used for data transmission only. This term was first defined by Martin Fowler as a negative example of a design pattern. A typical example relies on the ability of objects to store data, but the business logic resides in services and other external resources.

Continue reading 

Once upon a time, there was an object named “Component”. This object was used to perform a specific function. However, sometimes it was necessary to extend or modify this function. That’s where “Decorators” came into play. Decorators are objects that “decorate” or extend the Component. A Decorator comes on top of a Component and extends or modifies its function. This is used to extend the functionality of the Component without changing it itself.

Continue reading 

Once upon a time, there were two friends from two different worlds: the Electric Vacuum Cleaner and the Electric Outlet. The Electric Vacuum Cleaner needed energy and wanted to get this energy from the Electric Outlet. However, there was a problem. The plug of the Electric Vacuum Cleaner did not fit the Electric Outlet. They were both produced in different standards and could not communicate directly with each other. In this case, a hero emerged: the Adapter.

Continue reading 

Murat: The Transaction Script pattern allows transactions to be carried out simply and smoothly. However, using this pattern can make understanding and maintaining the code difficult for applications with complex business logic. Epictetus: Yes, Murat. But we must not forget that everything depends on complexity. The Transaction Script pattern can be an excellent choice for applications with simple business logic. However, as the business logic becomes more complex and requires many transactions, other patterns such as Domain Driven Design (DDD) may be more suitable.

Continue reading 

The Transaction Script is an Enterprise application design pattern often used in transaction-based systems. This pattern is created by bringing together a series of procedures to perform a transaction. These procedures are typically used to initiate a transaction, run database queries, and process the results. The Transaction Script pattern is suitable for applications with non-complex business logic. However, as the business logic becomes more complex and requires many transactions, using this pattern can make understanding and maintaining the code difficult.

Continue reading 

Overview The SemaphoreSlim class is a structure used in C# to control one or more threads using a specific resource or operation concurrently. SemaphoreSlim limits the number of threads that can access the resource at the same time. The use of SemaphoreSlim is often used to prevent deadlock situations in multi-threaded applications and to ensure that a specific resource is used by only one or more threads at the same time.

Continue reading 

Once upon a time, there was a ruler in the Singular Realm. The ruler’s name was “Singleton”, and he had the property of being the only entity in the whole realm. Singleton had educated everyone else about preserving his uniqueness and singularity. Being the sole ruler of his kingdom, Singleton was recognized with the property of being a unique entity that, once created, could not be changed again. In every corner of the kingdom, it was known that Singleton was created only once and only one instance existed.

Continue reading 