Introduction

As the design and writing of code shift to AI, developers will need to understand the inner workings of a system in less and less detail, and will increasingly be able simply to describe what it is supposed to do. Ordinary conversational language is not suitable for this purpose, as it allows for multiple interpretations. What we need, therefore, is a language that is close to natural language but sufficiently unambiguous for AI to transform a description into a working system. Such a language is based on a conceptual model, that is, a set of concepts used to describe the business. The more naturally these concepts reflect business logic, and the easier it is to translate that logic into code, the better the model. In our view, an event-based model meets these requirements well, as it allows us to describe the business in terms of facts that have occurred and processes (rather than entities and their relationships), while Event Sourcing (ES) provides the architectural foundation for its implementation.

Diagrams from Event Storming, Event Modeling and related approaches can serve as a “programming language” based on this model. Clearly, such a language does not contain, nor should it contain, any infrastructure mechanisms, such as dispatching, publishing, invoking handlers, and so on. This means that AI would have to design these mechanisms from scratch each time, which, in turn, would lead to errors. To avoid this, we need not only a language but also a framework that takes on the generic mechanisms and leaves AI only what is specific to the particular system: business logic, connections to external services, repositories, queries, projections, and so on. Axon, for example, can serve as such a framework for Event Sourcing.

The purpose of these publications is to provide a comprehensive understanding of the conceptual model underlying ES architecture and, through a series of examples, demonstrate how various problems can be solved using Event Storming/Modeling diagrams.