Domain-Driven Design
verraes.net
Domain-Driven Design
1–10 of 198 posts
Re: Domain-Driven Design
#2Who is Mathias Verraes?
Re: Domain-Driven Design
#3Who is Mathias Verraes?
He has an "About" page and links to his LinkedIn profile on his website.
Re: Domain-Driven Design
#4If someone wonders about DDD, I'd recommend Lightbend's free courses, e.g. [1]. They don't go too in-depth and you can take all of them (I think five?) within a weekend.
[1] https://academy.lightbend.com/courses/course-v1:lightbend+LR...
Re: Domain-Driven Design
#5[deleted]
Re: Domain-Driven Design
#6I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with experienced Java developers with deep Enterprise Software(tm) knowledge.
Then, I started working as an AI Software Engineer (mix of a software engineer + devops + data scientist), and it all clicked. DDD is a wonderful design pattern for anything related to Data Science, AI, ML. Why ? because 90% of your problems is retroactively making sense, organizing, sorting, filtering, aggregating all the data you got from your favorite Data Base/Lake/Wharehouse. DDD let you have a unified language, invariant definition and expectations between your existing business challenges and the analytics your are running on it. It's very good for validating assumptions accross a dataset, for example: Sales amount can never been < 0 ? Let's check that... Oh well, you forgot about returns, so now you can define them and be explicit when to include or exclude them.
Re: Domain-Driven Design
#7> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ...
> DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. ...
> That makes DDD notoriously hard to define.
I don't know anything about DDD, but if you can't concretely describe it and how it's different to how teams naturally work together, how can it be actionable and what stops it becoming another cargo cult when nobody can agree on what it is?
Re: Domain-Driven Design
#8Who is Mathias Verraes?
* Disclaimer: Mathias is a personal friend of mine, and I was heavily involved in the European DDD community over a decade ago. *
Mathias is one of the original instigators of the European DDD community: he spent the last decade giving talks all over Europe about DDD and organizing one of the largest DDD conferences in the world: DDD Europe [0].
Next to this he also has a consulting org (recently rebranded to Aardling [1]), and spends a lot of time with DDD gurus like Eric Evans (the "inventor" of DDD, author of the DDD blue book), Alberto Brandolini ("inventor" of event storming), Nick Tune, Paul Rayner, Yves Reynhout, Cyrille Martraire, Romeu Moura, Marco Heimeshoff, ...
As far as I'm concerned, he's the real deal, and has skin in the game. Highly recommended!
Re: Domain-Driven Design
#9I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with experienced Java developers with deep Enterprise Software(tm) knowledge. Then, I started working as an AI Software Engineer (mix of a software engineer + devops + data scientist), and it all clicked. DDD is a wonderful design pattern for anything related to Da…
And the most important thing is that you have clear benefits in communication using a common domain language.
Re: Domain-Driven Design
#10> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…
I recently came across this talk from Scott Wlaschin titled "Domain Modeling Made Functional".
I found it a great practical introduction to DDD.