This post explains why and how Read Models can be useful on the write side of a software. First, the terms CQRS, write side, read side and Read Models are briefly explained. Then, it is discussed how the read side works and why Read Models can also be used in other areas. Next, one common use case for read data on the write side is described. As last part, the whole topic is illustrated with a simplified example.

The many ways of CQRS

CQRS is a pattern that separates software into a write side and a read side. The idea is to treat write-related use cases differently from the ones that primarily yield data. However, the concept itself does not dictate any technological decision. Specifically, it does not demand to use separate data storages. Although this is a common setup, it is completely optional. Even the sole use of a caching mechanism or a view in an SQL database are some form of CQRS.

What is a Read Model?

A Read Model is a data structure for displaying information that is in some way based on a Write…

This post summarizes some insights from my deep dive into TypeScript from when writing an appendix for my book. While I have been working with TypeScript for quite some time, most of the code I encountered was pretty trivial. The majority of the following aspects were new to me and helped me to understand the language better. Also, writing a lot of my book’s code again in TypeScript allowed me to identify potential downsides.

Class magic

TypeScript has a special support for the class keyword. For every class within the global scope (of a module), it implicitly defines an instance type with the same name. This enables to write things like const user: User = new User(). Unfortunately, this mechanism does not work for dynamically created classes or plain constructors. In such cases, the behavior must be emulated with the utility InstanceType and the keyword typeof. Interestingly, export and import statements combine same-named values and types.

The following code illustrates this behavior:

class StaticClass {} const a: StaticClass /*type*/ = new StaticClass(); /*constructor*/ const createClass =…

This post illustrates a Domain Modeling process using a simple example. As first step, the actual problem is identified. Next, a solution approach is discovered. This is followed by the creation of an initial Domain Model. Afterwards, a first implementation is provided. Then, technical and logical challenges are discussed and solved. Also, the differences between a Domain Model and its implementation are explained. The post ends with a recommendation to use a problem-centric and model-driven approach, even for small projects.

Problem identification

Domain-Driven Design puts emphasis on the problems to solve and its involved knowledge areas. In my book, a Domain Model is defined as “set of knowledge abstractions that is focused on [..] solving specific problems”. This means, in order to create a useful model, one needs to identify the problems first. As specific example, consider the following problem I encountered during the time when I was working on my book: I want to know the occurrences of individual words in a text.

At first, this statement seems useful. However, it is not really describing a problem, but already implying a…

This post describes the approach of using the filesystem for illustrating the implementation of concepts related to persistence and messaging. Some of the explanations are put into the context of my book “Implementing DDD, CQRS and Event Sourcing”. The approach is compared to the alternatives of using existing technologies as well as providing pseudo in-memory implementations. At the end, the post outlines the most relevant benefits and implications.

The approach

Apart from Node.js and JavaScript, my book does not explain or utilize specific frameworks or technologies. For all functionalities that require persistence or inter-process communication (IPC), it provides exemplary implementations that work with directly the filesystem. This includes Repositories, the Event Store, Read Model storages and an inter-process event distribution. The goal is to convey a deeper understanding of the concepts that are related to persistence and messaging. For production purposes, these implementations can be easily replaced with suitable technologies.

As example, the following snippet shows a basic variant of a generic filesystem-based Repository:

class FilesystemRepository {  storageDirectory; #convertToData; #convertToEntity;

This post explains why I chose Node.js as runtime platform and JavaScript as programming language for my book “Implementing DDD, CQRS and Event Sourcing”. The described reasons incorporate personal experience, the desired target audience, as well as platform and language characteristics. Also, the benefits and implications of static types are briefly discussed. Finally, the post closes with an outlook of future additions to the existing book.

Personal experience

One reason for using Node.js and JavaScript in my book is that I’ve worked with both for almost 8 years. As for JavaScript as a programming language, I have around 14 years of experience. Also, two projects in which I applied CQRS and Event Sourcing made use of those technologies. Therefore, it seemed like a natural choice for me when I planned to write a technical book.

Broad audience

Another reason for JavaScript is that it is a very widespread language, with which I can reach a broad audience. While not everybody may like it, there are many people who understand it…

This post explains my motivation for writing a book on DDD, CQRS and Event Sourcing. It starts with outlining how I came in contact with the concepts. Then, it describes how I first applied the patterns accidentally and afterwards worked with them extensively. Finally, it presents the initial book idea, my personal progress throughout the years and the actual result.

First contact

I first heard of Domain-Driven Design when I worked as a Senior Software Developer at AutoScout24. It was in 2012, when colleague developers told me about the concept and recommended “Domain-Driven Design” by Eric Evans. I immediately bought the book, but only skimmed it initially. Although I was working as a full-stack developer, I was primarily focused with UI development at that time.

Either also in 2012 or in 2013, I got introduced to CQRS and Event Sourcing. First, a few colleagues started to talk about the concepts. Some time later, Greg Young gave a workshop at AutoScout24. While I…

Alex Lawrence

Full-Stack Developer, Technical Lead, Software Architect

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store