Murat Genc

The Uniqueness of the Rust Programming Language Rust is a modern systems programming language that aims to offer memory safety, concurrency, and high performance together. One of the most significant features of Rust is its memory management model. This model is based on the concepts of “ownership” and “borrowing”. The Importance of Ownership and Borrowing Concepts Ownership and Borrowing are the cornerstones of Rust’s memory management model. These concepts enable Rust’s memory safety and concurrent operation.

Continue reading 

Hello! If you are interested in the Rust programming language, you have probably encountered the Option type, which is quite important for you. This type is one of the standard solutions that Rust provides for error handling and managing values that could be null. What is the Option Type? Rust uses the Option<T> type to manage null values or non-primitive values. This is perfect for marking situations where a specific value T could exist or might not exist.

Continue reading 

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 

Once upon a time, there was a kingdom, and the name of this kingdom was “Abstract Factory”. Although it seemed abstract, everything in this kingdom had a purpose, a certain order, and a specific design. There were certain rules on how everything was made, and these rules were based on design patterns that regulated the creation of objects. In the kingdom of Abstract Factory, the King, known as AbstractFactory, would manage the factories of different types of products.

Continue reading 

Once upon a time, there was a very beautiful kingdom, and its name was “Builder Pattern”. Everything in this kingdom was about the art of constructing complex objects step by step and connecting them together. These complex objects were the most valuable treasures of the kingdom, and each one was carefully and thoughtfully constructed. The wisest person in the kingdom was this master named the Builder. The Builder would construct complex objects using materials like stones, bricks, and wood.

Continue reading 

Once upon a time, there was a magical kingdom, and its name was “Factory Method”. This kingdom was a place that controlled the creation of objects. The wisest ruler of the kingdom believed that the creation of objects had its own special ways, and this was part of his rule. The ruler had a princess, and her name was “Creator”. Creator used her magical powers every day to create a new object.

Continue reading 

Once upon a time, there was a place called the Land of Creators. In this land, there was a secret to creating new objects quickly and efficiently. This secret was called the “Prototype Pattern”. One day in the Land of Creators, there was a magical drawing pen. This pen had the ability to copy any object it touched. This feature made the creation of objects easy and fast, because instead of creating each object from scratch, an existing object was being copied.

Continue reading 

When working with databases, it is of great importance to properly manage concurrent operations and ensure data integrity. Concurrency control is used to manage multiple users or processes accessing the same data concurrently. In this article, we will explore how to ensure data integrity using LINQ (Language Integrated Query) with optimistic concurrency. What is Optimistic Concurrency? Optimistic concurrency is a method where resources are not locked when a transaction begins, but changes are checked before the transaction is completed.

Continue reading 

When working with databases, managing concurrent operations and ensuring data integrity are of great importance. Concurrency control is used to manage multiple users or processes accessing the same data concurrently. In this article, we will explore how to use LINQ (Language Integrated Query) with pessimistic concurrency to maintain data integrity. What is Pessimistic Concurrency? Pessimistic concurrency is based on the principle of locking the relevant data when a transaction begins and maintaining the lock until the transaction is completed.

Continue reading 

In another corner of the Land of Computers, in the City of Microservices, there was another world where all microservices moved according to a specific symphony. In this world, all microservices were governed by a single orchestra conductor, and this management model was called “Orchestration-Based Saga.” This resembled a music performance in a grand orchestra. Just as an orchestra conductor tells all musicians when and which notes to play, in this world, the Orchestra Conductor Microservice determined when and how all microservices would move.

Continue reading 

In another corner of the Land of Computers, in the City of Microservices, there was another world where all microservices moved according to a specific symphony. In this world, all microservices were managed by a single orchestra conductor, and this management model was called “Orchestration-Based Saga.” It was akin to a music performance in a grand orchestra. Just as an orchestra conductor tells all musicians when to play which notes, here the Orchestra Conductor Microservice determined when and how all microservices would move.

Continue reading 