Architecture

Is it true that domain events must be handled in the same process? According to .NET Microservices: Architecture for Containerized .NET Applications, that is the standard approach. This rather radical statement raises some questions. Let’s investigate this further. How do DDD experts define a domain event? Eric Evans: “Something happened that domain experts care about” src. Vaughn Vernon: “Domain Events will help you … to share what has occurred within your model with the systems”. ...

Despite the large number of application design approaches, two main ones stand out: Transaction Script Domain Model The first is simple and allows for conveniently organizing code into separate procedures that process external requests. However, as application logic becomes more complex, spreading it across many procedures leads to code duplication and other issues. Furthermore, mixing database interaction with logic processing complicates unit testing and reduces code reliability. On the other hand, using a Domain Model at the start often seems like over-engineering, adding significant code without guaranteeing freedom from errors. However, in the long term, this approach enables the creation of programs with complex domain logic without an exponential increase in complexity. ...

Blockchain system architecture is a very interesting subject. Despite its apparent complexity, it consists of fairly simple elements widely used in the software industry, not just in blockchains. It is both complex and simple at the same time. A paradox? Let’s identify the key elements that make up all blockchain systems and distributed ledgers. Event Store Let’s start from the beginning. Users interact with blockchains by sending transactions. We won’t detail transaction signing; while cryptography is fascinating, here it serves only as a validation stage. Transactions—user requests to the system—are sent, validated, queued, and stored forever. This suggests the use of the Event Sourcing pattern. This means one can always process the entire event sequence to derive the system’s current state. Since events are stored indefinitely in strict sequence, we can conclude that a blockchain is a kind of event store. Kafka is a popular event store option in traditional software development. ...

What do useful patterns for implementing reliable high-load software systems like CQRS, Event Sourcing, and EDA have in common? All of these patterns are based on working with event streams. Despite the simplicity of this concept, there are surprisingly few ready-made tools for its implementation, with Kafka being the only widely popular one. Often, people do not distinguish between the concepts of event streams and message queues, which leads to misunderstanding and underestimation of the prospects of using event streams. Let’s get to the point. ...

Today, I would like to discuss domain entity states. Recently, I came across a video and an article on the blog of an interesting software developer. In this article, he discusses exactly what I covered in my previous post regarding the separation of an entity and its state. Although phrased differently, he presents the same arguments for separation. I would like to elaborate on states and their storage. As noted earlier, saving entities essentially means saving their states. Generally, it is inaccurate to speak of saving entities, as an entity represents behavior stored in your application code, not the database. This leads to confusion with ORMs, particularly Entity Framework, which attempt to implicitly extract the entity’s state for persistence, causing difficulties in non-trivial cases. It is often more convenient to explicitly define the entity’s state as a separate class. ...