Engineering Log

In his post about Clean Architecture, Robert Martin highlights use cases (or interactors) as a key element of application architecture. He describes the purpose of use cases as follows: These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case. While the description might not be immediately clear, the main idea is evident: we receive data and pass it to domain entities. ...

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. ...

The classic implementation of the application persistence layer is ORM. Its advantages and disadvantages have long been known and described many times, for example, by Martin Fowler. In short, the main problem with ORM is that OOP objects describe the behavior of entities, while ORM attempts to work with the data inside them. However, the ORM lacks information about which class fields represent the entity’s state that needs to be saved. To provide this information, you must mark these fields or describe the persistence logic elsewhere in the code. Often, ORM is used incorrectly due to a misunderstanding of its specifics and the universal nature of its implementation. ...