UML diagram for the DDD example in Evans' book
https://github.com/takaakit/uml-diagram-for-ddd-example-in-evans-book

UML diagram for the DDD example in Evans' book
https://github.com/takaakit/uml-diagram-for-ddd-example-in-evans-book
New article on our blog
Silas Joisten writes about a new way to write tests in #Symfony. Explore Zenstruck Foundry
Read the full article here
I hate it when business internals are poorly abstracted.
In software, there's a thin line between #DDD, where the business-domain shapes software to be more useful, and where it pushes software to be confusing or harmful.
I opened an account at IONOS (to move some hosting to the EU). IONOS.nl makes me "choose a language". My German is OK, my English better. So I went for English.
I'm now paying my invoices in British £ to a daughter comp outside the EU. With tax and forex implications
One thing I dislike about all #CRDT libs I found is their CRUD-like modle. I'd really like to use #DDD style domain events and then turn them into a CRDT. That would allow domain-specific conflicts and domain-specific resolution.
I wonder if anyone has done that? I have currently created a small POC and I seem to like it, but I also feel that implementing the CRDT logic myself is just too error prone.
Had finally time in the weekend to write a new blog post about the new features for our latest releases of patchlevel/event-sourcing. So if you want something to read for the weekend you can check it out here: https://patchlevel.de/blog/what-is-new-in-php-event-sourcing-3-9-and-3-10
Who's going to EXPLORE DDD next week in Denver? I am! If you are, too, let me know, would love to meet in person. I want to talk all about DDD, event-sourcing, event modeling and storming, etc. Can't wait!
Just published an article inspired by the book club sessions with @matteopierro and @pietrodibello
I shared some of my reflections on #DDD, #EventSourcing, and #EventDriven architecture. How your system can grow towards that direction, and how things can be well decoupled each other.
I am always curious to hear what's your take! What's your approach in your codebase? What trade-offs have you faced?
Article is here
Why pay more for less? My online #DDD workshop goes deeper, lasts longer, and costs less than a typical conference workshop—plus, you’re learning from the guy who wrote the book.
Join me on May 13–16
#DDDesign
#DomainDrivenDesign
Wenn man wirklich so ignorant ist, Gender-affirming-care zu verbieten, sollte das auch die Gummihupen-Chirurgie an unter 21-jährigen, welche ja gerade in den USA das Symbol der ganzen (MAGA-affinen) Gesellschaftsschicht ist, mit einschließen.
Geschlechtsbestätigung kann alles heißen. Vor allem heißt es Anerkennung. Gesellschaften die ihren Kindern Behandlung verweigern sind nur noch einen Schritt von KZs entfernt.
Ist ja wieder mal klar, dass keine einzige Stadt aus Deutschland dabei ist.
Aggregates, event sourcing and event storming are concepts you regularly encounter when talking about #DDD and while important, they're not essential. It's a shame to see many people lose interest because of these concepts. DDD is foremost a warning to not overzealously normalize data models. It's about identifying where boundaries should exist between features in order to minimize the blast radius of changes, and how information can be carried across those boundaries without tight coupling.
It should be recognized that reducing a team's cognitive load includes speaking the same language as the business in specific contexts.
The cognitive energy required to translate from business concepts to technical concepts, and technical concepts to business concepts, is enormous.
Do you need to reduce cognitive load? Start with a common language. #DDDesign #DDD #DomainDrivenDesign
Will AI untangle your Big Ball of Mud?
Can it identify your Bounded Contexts?
Can it architect your systems with clarity and purpose?
Not yet. But "Implementing Domain-Driven Design" (DDD) will.
Learning is essential—but applying that knowledge is what truly transforms your organization. Are you ready to put your knowledge to work?
Join me for hands-on learning to tackle complexity.
Register today.
14:00 Berlin CET
09:00 AM New York EDT
Don’t miss this opportunity to elevate your skills and bring lasting value to your software development efforts https://kalele.io
My sketchnote of Rebecca Wirf-Brock's talk on "Model Rigor, You Say".
Link to the talk on YouTube: https://youtu.be/WWaIkQ48bVY?si=fQ1wOC1ADwf4hG1u
I didn't find a way to "compress" the talk, so there is a loooot of text.
A good talk, but not well suited for a sketchnote.
If your interpretation of #DDD led you to overabstract and overengineer an architecture making it harder to comprehend and maintain than a simple CRUD application would have been, reconsider the core premise of any #softwaredevelopment philosophy: to provide solutions that anticipate the volatile nature of the problems they aim to solve. If separation of concerns leaves you with an unscalable mound of mappers and abstractions, it may be ok to sacrifice some of it to express intent more clearly.
Reflecting on past hypes in software development after 18 years in the industry.
Things that lived up to their hype:
Agile Software Development
RESTful API Design
Domain Driven Design
DevOps
Containerization
Event Driven Architecture
Team Topologies
Things that didn't live up to their hype:
SOA
Hexagonal Architecture
Blockchain
Event Sourcing
Reactive Programming
Things in between:
Microservices
Machine Learning
To be seen:
AI
My sketch note of Rebecca Parsons' talk on Evolutionary Architecture and the Role of DDD (DDD Europe 2024)
Link to the talk: https://youtu.be/vK-Ut610wG0?si=Giklsq2oic2G9gmP