DDD in Gleam book

[lavish elm]

I saw that many DDD books rely on great type systems. As an exercise I wrote myself a curriculum, and worked through it. I decided it was easy enough to package the steps I took into a book, and here it is:

https://escherize.com/gleam-katas

[real dawn]

For anyone like me who hasn't heard of it before, DDD means domain driven design. Wikipedia describes it like this:

Under domain-driven design, the structure and language of software code (class names, class methods, class variables) should match the business domain. For example: if software processes loan applications, it might have classes like "loan application", "customers", and methods such as "accept offer" and "withdraw".

[warm frost]

This is incredible

[sonic quarry]

very nice

[candid rune]

ooooo

[plush kayak]

I love 💕 this. Very interested in 'functional-reactive DDD' since I watched the talk "Domain modeling made functional" by Scott Wlaschin. I noticed yesterday that @frank wraith was inspired to write Zwick multiplayer card game based on the "Make illegal states unrepresentable" concept in this talk, which is very well explained (don't think Zwick is open source though).

A number of architecture patterns fit very well together in all of this.

On CQRS/ES. There are various other Gleam projects that are useful to apply directly or as case study. Like @sour orbit CQRS/ES approach in eventsourcing and eventsourcing_glyn libraries, also coming with a SQLite adapter. For me very interesting is "Aggregateless event sourcing" which has a gleam exploratory prototype in gleavent_sourced by @dusty sparrow. @long oriole wrote signal, another event-sourcing lib.

Also very interesting to look at are the Uno card game projects that explore the Decider pattern, that @cyan depot wrote about. @fringe tundra created uno as a PoC that uses this. What I liked here is the terse code that maps almost one-to-one to a Gherkin BDD test. There's the library dream_test that may fit here too.

Getting non-technical stakeholders along during solution design is a big benefit. Via Event modeling for instance. See Fraktalio domain modeling.

[marsh stag]

did you use claude at all to write some of the book ?

[plush kayak]

No, I used time and a keyboard. But I have a tab stash where all the links sit together, so that helped 🤗 These questions do sadden me though, though I understand why they are asked. I am someone who always used to be more elaborate in online comms as a long-time community facilitator, and I call this "weaving in public". These days that raises suspicion. Yesterday on fedi I tooted my tiredness of the whole LLM shebang quoting the great blog post I found via this discord.

🫧 socialcoding.. (@[email protected])

Are you also so tired of #LLMs? 😩
Thanks John Lindbakk for summarizing..

lindbakk.com/blog/im-tired

social.coop · May 27, 2026, 8:51 AM

What I wrote above connects to my interest for the W3C ActivityPub protocol, and the observation how the fediverse diverges from its promise and power by protocol decay and tech debt. Wrote a huge blog post on that, also totally hand-crafted. And I got some of these same questions too.

[signal forum]

I know a few autistic people who get told that their sound like llms. Or get accused that they let llms write their homework.

[marsh stag]

wicked, thank you for answering in earnest 💕

wait

i meant OP oops

not you 😂

[plush kayak]

No problem @marsh stag I was not offended. I am a humane technology activist, and the way AI/LLM is introduced makes it the most horrible inhumane tech in how it'll likely erode the social fabric of society.

A lot of people apparently change their writing style, put in spelling errors, swear words, avoid bullet lists, etc. In any case, to put this back on topic, the Aggregateless Event Sourcing fits very well with a service-oriented fediverse, where independent services compose, orchestrate, and choreograph together in interesting ways. A fediverse that rises above the app-centric one we have today, which are basically apps connected with narrow pipes to the next app, and require "whack-a-mole" development to keep them from breaking by each other app they integrate with if there's a change in the codebase..

[plush kayak]

(and I cross-posted happily along 😂 )

Perhaps it might be an idea to add a Resources page to the kata docs to point people through to the prior art in the gleam community.

There is ProFed, a fediverse project in Python, that is based on Event Sourcing.

[elder crater]

amazing, definitely will spend some time reading this knowledge

[plush kayak]

Note that gleam is particularly interesting here with its native support for the actor model. The ActivityPub protocol is actor-based. A nice functional-reactive DDD design sees the Aggregate Root in the domain layer (functional core) be fronted by an Actor in the services layer (imperative shell).

Or a dynamically 'gathered' bounded context when using aggregateless event sourcing.

Going aggregateless in a fediverse context alleviates problems where over time all the various bounded contexts that are exposed as services become too rigid.

If anyone is interested to explore creating a fedi project, I'd be happy to learn about it. I am merely a generalist myself, currently on 'hobby track' without $$$ pecunia, going sloooowly. 😆 😢

[signal forum]

I am interested but i already have too many side projects.

[fringe tundra]

I shared this at work and someone said "you finally gave me a reason to try gleam"

[pallid ocean]

@plush kayak on the topic of aggregateless events you may want to look at DCB: https://dcb.events/ if you haven't already, lots of prior art there as well if you want to build your own eventstore. Sara Pelligrini and Milan Savic's talk which made the rounds a few years ago within the DDD community may also be of interest: https://www.youtube.com/watch?v=IgigmuHHchI

[fringe tundra]

I am a fan of the Kill Aggregate talk

[plush kayak]

Thank you @pallid ocean. Yes, it sat in my stash tab, but the video is new for me. Will watch 😃

tab stash, rather

[plush kayak]

I watched the vid, and yes, fan of killing the Aggregate @fringe tundra. Concepts are explained clearly and comprehensively in the talk. Using the method we get a Dynamic Consistency Boundary based on a StreamQuery that can relate to one or more DomainEvent, and the events stand on themself, are not owned by the aggregate.

[fringe tundra]

Aggregates feel so artificial and OOP

[wicked heart]

Excited to check this out! 👏

[late verge]

What a really good introduction to DDD. I've read a little about it in the past and found it a little daunting to understand. This makes the concepts easy to understand.

[steel kraken]

dream_test isn't by me 🙂

[plush kayak]

Thanks, edited that. Can't find if the creator is on this discord.

[sage quiver]

This is very nice, I'm defintely going to read it through. Out of curiosity, can I ask how you build the book? I saw the gh-pages branch but couldn't figure out how it's generated

[steel kraken]

I am using unitest and it is very nice

[plush kayak]

Looks good. In the context of DDD the Gherkin behavior tests are quite nice as plain text formulations in the 'ubiquitous language' that non-technical folks (the domain expert) understands. In that context I name-dropped dream_test, which as a project does more than I need.

[late verge]

I used gleeunit/should when I implemented the tests:

pub fn place_fails_on_placed_order_test() {
  let assert Ok(#(order_with_line, _)) =
    empty_draft_order() |> order.add_line("sku-1", 1, usd(150))

  let assert Ok(#(placed_order, _)) = order_with_line |> order.place

  placed_order
  |> order.place
  |> should.equal(Error(order.CannotModifyPlacedOrder))
}

I went back and forth on if I like using let assert for the setup data or liked using should.be_ok to unwrap the Ok().

I settled on mixing the two so that it is clear what is setup code and what is the test's assertion.

I'm still not convinced I made the right decision.

pub fn place_fails_on_placed_order_test() {
  let #(order_with_line, _) =
    empty_draft_order()
    |> order.add_line("sku-1", 1, usd(150))
    |> should.be_ok

  let #(placed_order, _) =
    order_with_line
    |> order.place
    |> should.be_ok

  placed_order
  |> order.place
  |> should.equal(Error(order.CannotModifyPlacedOrder))
}

[torn spade]

Btw, gleeunit/should is deprecated, you should use assert now (you get benefits such as better error messages)

[late verge]

oh good to know

[late verge]

I see. I used gleeunit/should because I thought it had nicer error reports, but assert is just as nice. I understand why it is deprecated now

[candid rune]

Should has much worse reports

Functions are very limited compared to built in syntax

[plush kayak]

For the dev these are very nice readable tests, but the domain expert needs to be carefully explained line by line to convince them that they assert the correct behavior, and they can't read it back on their own and understand when the dev is not around. I'd like to be able to send the behavior stories e.g. by email and have them serve as the 'contract' between devs and the client stakeholder. The story texts being Gherkin means they are living documentation, guaranteed to be in sync with the code and part of the executable test suite to demonstrate conformance.

You might say the gleeunit tests are written in the devs domain, not in the domain expert's domain the client/customer expects.

[candid rune]

Nothing stopping you from using gherkin in Gleeunit or outside of it. You have full control over what code your tests run!

[solar axle]

@plush kayak thanks for the all the references. Really helpful.