Collecting a bunch of links here that I have meant to record for a longer time.
https://kerkour.com/rust-combinators A good introduction and overview article about combinators and iterators in Rust. Especially if you’re new to the language.
https://web.stanford.edu/class/cs25/ A Stanford class about Transformers (the neural network architecture). With an introduction to the architecture itself by Andrej Karpathy
A colleague recently mentioned the concept of Clean Architecture (as named by Uncle Bob Martin). The essential idea is to have
a layered software architecture,
with the domain objects and business logic at its core
and all dependencies only pointing inwards
Uncle Bob uses 4 concentric circles to denote the layers of a generic architecture and calls them (from inside to outside): Entities, Use Cases, Interface Adapters and “Frameworks and Drivers”. The outermost layer contains all technical details like the type of database that is used and which web framework (or UI or whatever) is applied.
Of course, Uncle Bob would not be Uncle Bob if he would not suggest to use the dependency inversion principle to have the control flow point in the opposite direction as the dependencies. In my current job, where we work mostly in Rust, we would most of the time rely on traits and in particular the SerDe crate to take the role of the depedency inverter.
Layered Architecture in DDD
Not so long ago, I tried to read the book Domain-Driven Design by Eric Evans. It was also recommended to me by a colleague. But trying to read it I had a really hard time working myself throug the book. The writing style somehow didn’t connect with me that well.
But then, more recently, I did discover the DDD reference which is a little summary of the patterns and definitions of DDD that is also authored by Eric Evans and that can be downloaded for free on this website: https://www.domainlanguage.com/ddd/reference/
I mention this book here because it also has a section on Layered Architecture in which it says:
Isolate the expression of the domain model and the business logic, and eliminate any dependency on infrastructure, user interface, or even application logic that is not business logic. Partition a complex program into layers. Develop a design within each layer that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above.
Today, Youtube recommend this talk by Nick Tune to me:
I had actually never heard of Nick Tune nor the NDC Conferences before, but the title certainly struck a chord with me. For one, I am currently reading the book Team Topologies and I recently started learning about Domain-Driven Design. So overall, good job Youtube alogrithm!
Now, the talk itself became most interesting to me in its last part, the part about indentifying and strengthening your company’s core domains. The first part was mostly about Event Storming, a technique that Nick seems to be using a lot as a consultang. The second part was a short introduction to Team Toplogies. The concept of the independent service heuristics sounded quite interesting and worth mentioning here.
So for the rest of this post, I will mostly collect links that have been mentioned in the talk and maybe summarize some of the techniques that are mentioned there. I really liked the fact that Nick Tune and team have github organization called Domain-Driven Design Crew.
Independent Service Heuristics
The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. Based on some of the ideas in the book Team Topologies by Matthew Skelton @matthewskelton and Manuel Pais @manupaisable.
This is essentially a checklist, or question catalogue, of 20-30 items that you shold try to answer. The more “yes” or “probably” answers, the greater the chance that you have found a good candidate for being a separate stream of change.
Core Domain Charts
As mentioned above, the third part of the talk is mostly about applying Core Domain Charts to different case studies and identifying patterns and anti-patterns wihin the framework.
Core Domain Charts is a set of visualization techniques that is available as a github repository on the Domain-Driven Design Crew’s github. It’s essentially using 2 types of charts, one where business domains are sorted by the axes “Business Differntiation” and “Model Complexity”,
and a seocond chart, more for the purpose of finding out about useful migration paths, where the axes are “Business Differentiation” and “Migration Complexity”.
Nick Tune identifies 3 main areas in the Core Domain Chart: The acutal core domain (defined by highest business differentiation, the supporting domain (also called table stakes features) and then, lastly, generic subdomains (things that you typically want to by off the shelf where possible).
The main strategies to improve on your subdomains is by exploiting (find complexity that can increase differentiation, i.e. migrate towards top right) and eliminate (find unnecessary complexity and get rid of it if it doesn’t harm your business differentiation, i.e. migrate towards bottom wherever you are on the x-axis).
Some strategies he mentioned in the talk:
Watch out for Hidden domains
Decouple supporting domains for fast flow in core domains
Put your efforts into a Decisive core
Watch out for indefensible cores
Try to find a revenue stream for Big Bet Future Cores
Take your High-leverage Supporting Subdomains seriously
Suspect Supporting: Try to reduce the complexity in those, maybe their codebaes has just grown old over time
The techniques summarized in this repository seem to be an elaboration on the chapter “Distillation for Strategic Design” in Eric Evans’ book Domain-Driven Design.
🧮 andreas.hartel.me 