DDD Weekly: Issue #51

December 14, 2017

You are also opting in for interesting, DDD-related emails from buildplease.com

DDD Persistence: Recorded Event-Driven Persistence [blog] Erik Heemskerk. When you decide to implement your business logic by applying DDD, one of the things you’ll run into is ‘how do I save my changes?’ The internet is full of blogs and articles about the mythical DDD repository, but all they offer is an interface. How do you actually implement it?

AsyncAPI Is A Specification Format For Message-Driven APIs [blog] Kin Lane. I’ve been learning about a new API definition format called AsyncAPI that allows you to define message-driven APIs in a machine-readable format. It is protocol-agnostic, which means you can use it for APIs that work over MQTT, AMQP, WebSockets, STOMP, and other real-time, and Internet of Things focused APIs. The specification format mirrors OpenAPI, making it pretty easy to get up to speed understanding what is going on.

The business case for event sourcing [blog] Frans van Buul. Conferences, meetups and Twitter are buzzing about “event sourcing” (ES) these days. The concept often gets linked to domain-driven design (DDD), which has some merit but is not the essence. Also, it sometimes gets placed in a highly technical context. At AxonIQ, we work with a lot of organizations that have built applications using Axon Framework and the majority of them use event sourcing (the framework leaves that choice open). Although event sourcing has clear technical benefits, our observation is these are not driving it. It’s the business benefits. Let’s have a closer look.

The Entity Service Antipattern [blog] Michael Nygard. I contend that “entity services” are an antipattern. To make that case, I need to establish that “entity services” are a commonly-rediscovered solution to a problem and that the resulting context is worse than the starting context (a monolith.)

SQLStreamStore vs NEventStore vs EventStore [github discussion] Damian Hickey.

One Bite At A Time: Partitioning Complexity [blog] Kent Beck. My final observation is just how frequently I fall off the complexity wagon. I want to be a genius programmer. I ought to be able to handle this. This time it’s different. Then I look up, realize I’ve been two hours without green tests, revert, take a walk, sit down, and go back to eating one bite at a time.

Functional Programming Means More Math, Or Does It? [blog] Vaughn Vernon. I have been striving to strike a balance between the need to accomplish real work with functional programming and trying to grasp the mathematics behind it. I am not saying that those who understand the mathematics of functional programming well don’t get real work done. Obviously they do. It’s just that I am thinking that I, and perhaps you, don’t need to know the advanced details of mathematics as well as they do in order to get real work done, too.

Practical Microsoft Orleans [blog] Derek Comartin. I’ve been wanting to take a deeper dive into Microsoft Orleans for awhile now. With the next release targeting .NET Standard 2.0, it felt like an great time to do it. This is the first blog post in a series that will go beyond a simple Hello World. The plan is to make this a practical Microsoft Orleans guide to follow along with.

Patterns for designing flexible architecture in node.js (CQRS/ES/Onion) [blog] Domagoj Kriskovic. In this post, I’ve presented a project that is using CQRS and Event Sourcing patterns. It’s organized using onion architecture and written with TypeScript.