Interesting learning resources - September 2025
Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined by Nick Tune
In this post from 2020 Nick beautifully explains key DDD concepts in easy to understand ways
Credit: Jeff Patton https://www.jpattonassociates.com/read-this-first/
What Kind of Programming is Natural Language Programming?
https://dsyme.net/2025/09/02/what-kind-of-programming-is-natural-language-programming/
No, Your Domains and Bounded Contexts Don’t Map 1 on 1 By Mathias Verraes
Bounded Contexts are a design choice to suit engineering needs
https://verraes.net/2025/08/domain-and-bounded-contexts-dont-map-one-on-one/
LIV BOEREE - a non-zero hero by James
What
https://dsyme.net/2025/09/02/what-kind-of-programming-is-natural-language-programming/
The Early History of F#
pdf This paper presents Don Syme’s perspective on the history of F#, structured around six key narratives. Syme describes how F# emerged from the collision between strongly-typed functional programming traditions and the object-oriented tidal wave of the 1980s-90s, particularly within Microsoft’s ecosystem. He explains how F# was born from an “obsessive compulsion” to ensure functional programming remained viable in the 2000s, starting with OCaml’s core but adapting it to interoperate with .NET’s industrial virtual machine and ecosystem. The presentation highlights how F# successfully resolved several contradictions within the functional programming community by introducing innovative features like functional objects, active patterns, and computation expressions. These additions allowed F# to maintain its functional core while becoming practical for real-world development, ultimately influencing many modern programming languages including C#, Scala, TypeScript, and others. Syme emphasizes that the “golden thread” of strongly-typed functional programming - exemplified by simple constructs like let f x = (x, x) - has remained constant from the 1970s through today and will continue to appeal to programmers in the future.
Code Review Can Be Better by matklad
This is a common pattern most of us use when reviewing code
When I review code, I like to pull the source branch locally. Then I soft-reset the code to mere base, so that the code looks as if it was written by me. Then I fire up magit, which allows me to effectively navigate both through the diff, and through the actual code. And I even use git staging area to mark files I’ve already reviewed … Alas, when I want to actually leave feedback on the PR, I have to open the browser, navigate to the relevant line in the diff, and (after waiting for several HTTP round-trips) type my suggestion into a text area.
Amazon’s ADR process
To read
-
The Three Kinds of Organizational Power by Jacob Kaplan-Moss. I did read this, but given the work I’m doing I need to dive deeper on this, thanks Anja Kunkel for sharing this write up with me.
-
https://www.caitlinsteele.com/open-pit-programming-silicon-valleys-industrial-extraction-of-human-potential-part-i-2/