Talk summary: Reactive DDD by Vaughn Vernon @ QCon2018

Some notes on the “Reactive DDD – When Concurrent Waxes Fluent” talk by Vaughn Vernon (author of Implementing Domain-Driven Design) at QCon 2018. (Currently I think you need to be logged in as a ticket holder to see the talk – I will post a link if it becomes public)

Moving from blocking invocations and “Anemic Domain Models”

In this talk, he starts by talking about the problem of how clients, typically, make blocking invocations to a server, and says that this is generally not well suited to the larger scale architectures we work on these days (I assume he means microservices). These blocking calls can be seen in object requests, HTTP request-responses, and in database calls.

The second problem he talked about is Anemic Domain Model – meaning classes/objects where there is not much behavior specified, just data and accessors (getters/setters). Such objects are often used to just map data into a database table and row. He makes the point that systems built using behavior rich objects have less code and are easier to test than systems built using anemic domain models.

Towards message driven architectures

Instead he thinks we are headed to message driven architectures, which he deems necessary because systems using blocking calls do not fully utilize CPUs, where as message driven architectures do and “can improve the overall throughput of the system”.

Message driven architectures include Event Driven architectures, where any kind of event can also serve as a message. And further, we actually create a concept in our domain model of an event, which represents a happening that we care about, “a fact”. That fact or event can be saved into a data source, and published/relayed to other subsystems who have an interest. EventSourcing is basically when events that get emitted, collectively represent the entire state of an entity.

The diagram below shows an event driven, and reactive, architecture. The controller sends a command message to an aggregate (an entity that has a defined transactional boundary), and that command can then be processed and, if accepted, an event is emitted. That event can be persisted and can even represent the entire state of the aggregate/entity.
And note that the commands can be queued – introducing the concept of an actor – and processed one at a time, in order, in a non-blocking manner. The actor doesn’t have to worry about concurrency violations.

 

Reactive

There can be problems with Reactive in that it may cause you to switch languages (?), and do you have testability and type safety (?), and the speaker advocates using Fluent APIs (?).

Because actors act in a very reactive or asynchronous way, we have uncertainty – how do we know if things have completed? So you may need something to represent a Progress status into your model to deal with that uncertainty, or asynchronicity in a reactive model.

The speaker goes on to say that in Reactive DDD (Domain Driven Design), you can think of a microservice as a “A DDD bounded context”, that is, something that is not a monolith, but is also not a single entity type. He suggests that these may be a better stepping stone in the transition from monolith to microservice.

Note that you can have a command model and a query model, segregated i.e. the CQRS pattern.
To have a reactive DDD ecosystem with microservice, you do not necessarily have to use CQRS, but it can be very beneficial.

Fluency

Vaughn talked about having fluency in your library and in your Domain Model.

Monolith to Microservices

A monolith that is well modularized as bounded contexts should be much easier to convert to a microservice. Some strategies from getting from the Big Ball of Mud (monolith) to bounded contexts include:

• Rewriting (“one bite at a time”, using change/value/test-driven approaches)
• Strangler approach e.g. using db triggers that raise events, or using Debizium or Oracle Golden Gate (basically, a database commit log tail-er).
• Restructuring: Find entities in the domain model, break those away, and turn those into a query model (used for the UI). One challenge is that the command and query models are eventually consistent.

 

 

 

 

Tags: conferencetalks, cqrs, ddd, qcon, qcon18, summary