Without being an expert in software architecture, I think there is definitely a performance disadvantage between tactical DDD compared to a data-centric approach. However, many times performance issues can be solved horizontally scaling the system. And that's the goal of the tactical patterns of DDD and clean architecture methodologies. To group software pieces with higher cohesion that change for the same reasons and at the same rate. One might say, that horizontal scaling can increase considerably the costs of operation of systems, but Uncle Bob has a point there. Machines are cheap and humans are expensive. If you compare the costs of instances compared to the salaries of people, you'll see that it's better to have a system that has a high cost of operation but low cost of development, to a system with a high cost of development and a low cost of operation. In the long run, highly optimized systems have a higher development costs because they're written for machines and not for humans. I'm not DDD preacher, and there are clearly cases where DDD rules need to broken, but it's a great starting point to adhere to them and evolve with the software needs. As a last comment, I wouldn't recommend this video to people that's just starting in the world of software architecture because it might be misunderstood. DDD is by far one of the best software philosophies there is.
Stefan always speaks ground truth. He reminds me of Allen Holub in that sense. There's a lot of talk about "architects" in the video and comments. An administrative empire that are "above writing code" is a red flag that should be picked up during interview. Most of our community's problems are rooted in inertia and the management of creative, collaborative, reactive and deeply intellectual work using ideas popularised in the 1900s. It's high time we let such companies die.
Engaging talk, here's my take-aways DDD emphasizes close collaboration among domain people, designers, UI/UX, business, product, and engineering. This collaboration enables a shared language and deeper understanding. The context is another key idea. The same word can mean different things depending on the team. So DDD emphasizes clear boundaries of meaning between sub-systems. A frequent pattern is defining the core layer of models and business logic, independent of any specific technology. And building the rest as replaceable layers around this core, like an onion. People call it hexagonal architecture or clean architecture. This is the model-driven way and useful in many cases but it's not the only way. Systems have different needs and usage patterns. For example, for a database-driven system, it might make sense to express this core layer with a relational database leveraging the strengths of the database system like relationships and constraints. In some other cases, it might make sense to drive design from UI experiments and user feedback. Another system might have a few core data types and many different operations on them, then a functional approach could be more expressive. The bottom line is that there is no one true way. A good idea is good in its context. Yet the core process is sound. When we listen well, collaborate, think deeply, and care about our work, the results are delightful.
If you're working by yourself on a fairly small project then perhaps not abstracting your domain logic core from incidental complexity might work. But even then things change and the architecture needs to be decoupled and robust to support those changes. An RDBMS centric system mixes essential and incidental complexity and makes changes progressively more difficult. I'm working on just such a system right now and it's a nightmare. Clean architecture is about allowing friction-free changes by decoupling system components.
Where I come from, DDD stands for Davai Davai Deploy, which roughly translates as "Come on, deploy already!" Needles to say, it's not considered the best practice, despite it's ubiquity.
Everything you said is true, but it is also all in the book itself! In several places it says that tactical design patterns are how DDD would be implemented in the 'OO world', but in other worlds like Functional or Relational patterns would be different, of course. Regarding the 'UI world', its a bit different, as what you describe as UI being at the center of the attention is actually driving the model by the UI (most notably aggregate boundaries and service layer), which is completely and perfectly fine. Maybe you are just interacting with a lot of 'Ortodox DDD' practitioners 😁 that interpret the book as the Bible instead of, as in your wonderful analogy, just a kitchen receipt for the main meat course! If the dish is vegetarian, then we should use the Functional paradigm of course 😂
Thank you for showing in a thoroughly manner something I'm advocating for so long: don't be dogmatic, take the theory and modify it to your needs to implement *your* version of DDD. Excellent presentation.
if Scala and Functional programming was mentioned, I click "Like" :-) Seriously, I think DDD became like Agile some time ago, i.e. lots of consultants promoting it as a viable methodology that one can't live without it, however you can. I agree that DDD is something we used for years without knowing it is DDD. I try to avoid DDD jargon to be not locked in one methodology.
> I try to avoid DDD jargon to be not locked in one methodology. That logic looks strange to me. "DDD jargon" gives you clear terminology for the certain concepts. Those word will be instantly understood by other people who are familiar with DDD, which makes communication more efficient. Why to forego the benefits?
@@xetas2 Lots of methodologies in the past had the same "feature" of trying to use the same "jargon" and most of them don't exist anymore, so, why DDD would be the savior at this time?
The most important thing to focus on and nail down, IMO/E, after figuring out what the bounded contexts are, is how state changes in a bounded context. For this, domain events are really useful, especially in a more behavior-driven approach where you're defining the state changes through the window of behavior. That leads to some incorporation of UI: spelling out that setting a widget's color to red means that afterwards the widget shows up as red in the UI (UI for this could just be HTTP API; the key thing is making it clear what information has to be included). If you have invariants that need to be enforced, then that leads to distinguishing commands and events and to needing a consistency boundary: the actor model is pretty useful here.
Great talk. For me the problem is that many architects follow the common DDD patterns but ignore everything else. I find that many companies do Pattern Driven Design, where they mandate the patterns without caring what the problem space is. Some companies I have worked at force everyone to use specific "DDD" libraries and patterns, but nobody collaborates with business, there is no common understanding of the model and no shared language with domain experts. A context map is some drawing on the architects machine that nobody cares about. But they say they do DDD because they call their objects entities and value objects.
Relational work makes a lot of sense when you are dealing with highly mutable data; and imply strong consistency; if it is replicated at all. Document databases make more sense when you need to replay events that created the data, so that lots of independent processors can respond; when actually altering things happens much less than adding new things. In those cases, strongly consistent islands, merged together with eventual consistency makes more sense. (ie: A replication log, where events need to commute to converge on a consistent result to handle partitions between the strongly consistent islands, etc.).
I hope DDD is forgotten very soon, unfortunately DDD advocates never stay to see how unmaintainable system ends up to be or if they stay they don't admit it, Dieter Rams' 10 Principles of Good Design made me hate it from the moment I had to use it.
After decades doing software development, I concluded that Architects are the bane of the industry. It's the role to which the most incompetent developers aspire, to ensure the demise of projects. This presentation confirmed it. Design is overrated.
If DDD is overrated, then this whole talk is overtheoretized. I've been using DDD for more than 10 years, and now I can't see any alternative approach deserving my attention. Especially when it comes to the security of architecture.
"I can't see any alternative approach deserving my attention", Sounds to me like that is the problem. I like the agility that is suggested with DDD but in practice architects just mandate a set of patterns and forget about everything else that comes with DDD. So would you say that the DDD patterns are perfect for every situation? Would all software be better off if everyone only used that set of patterns and nothing else?
@@brandonpearman9218 Again, DDD is not only patterns, as it was mentioned in the talk and as it was mentioned in the comments here. Patterns are only one chapter of the book. The blue book sets priorities, makes emphasis on things that matter, shows clear examples why. It is a whole tool box, philosophy, not just patterns. Personally, I have never seen such level of deep understanding of breaking down complex systems anywhere else.
@@snowy0110 yeah thats why i said "in practice". Most if the time the focus is on the patterns and nothing else, i think because its something which is easy to mandate on the teams. But the power of DDD is not the patterns. I would rather use everything else except the patterns, than just the patterns(which is how most do DDD)
Haha, DDD is overrated what a wonder! My problem with DDD, somebody should maintain all domain definitions, which in real word really hard job and believe me nobody wants to do that.
![[FULL EP.14] เซียนหรั่ง สอน มาร์ชจุ จับปูนา ฮากระจาย | เฮ็ดอย่างเซียนหรั่ง | One Playground](http://i.ytimg.com/vi/M8mPjd_T2lo/mqdefault.jpg)
Without being an expert in software architecture, I think there is definitely a performance disadvantage between tactical DDD compared to a data-centric approach. However, many times performance issues can be solved horizontally scaling the system. And that's the goal of the tactical patterns of DDD and clean architecture methodologies. To group software pieces with higher cohesion that change for the same reasons and at the same rate.
One might say, that horizontal scaling can increase considerably the costs of operation of systems, but Uncle Bob has a point there. Machines are cheap and humans are expensive. If you compare the costs of instances compared to the salaries of people, you'll see that it's better to have a system that has a high cost of operation but low cost of development, to a system with a high cost of development and a low cost of operation.
In the long run, highly optimized systems have a higher development costs because they're written for machines and not for humans.
I'm not DDD preacher, and there are clearly cases where DDD rules need to broken, but it's a great starting point to adhere to them and evolve with the software needs.
As a last comment, I wouldn't recommend this video to people that's just starting in the world of software architecture because it might be misunderstood. DDD is by far one of the best software philosophies there is.
Stefan always speaks ground truth. He reminds me of Allen Holub in that sense.
There's a lot of talk about "architects" in the video and comments. An administrative empire that are "above writing code" is a red flag that should be picked up during interview. Most of our community's problems are rooted in inertia and the management of creative, collaborative, reactive and deeply intellectual work using ideas popularised in the 1900s.
It's high time we let such companies die.
Engaging talk, here's my take-aways
DDD emphasizes close collaboration among domain people, designers, UI/UX, business, product, and engineering. This collaboration enables a shared language and deeper understanding.
The context is another key idea. The same word can mean different things depending on the team. So DDD emphasizes clear boundaries of meaning between sub-systems.
A frequent pattern is defining the core layer of models and business logic, independent of any specific technology. And building the rest as replaceable layers around this core, like an onion. People call it hexagonal architecture or clean architecture.
This is the model-driven way and useful in many cases but it's not the only way. Systems have different needs and usage patterns.
For example, for a database-driven system, it might make sense to express this core layer with a relational database leveraging the strengths of the database system like relationships and constraints.
In some other cases, it might make sense to drive design from UI experiments and user feedback.
Another system might have a few core data types and many different operations on them, then a functional approach could be more expressive.
The bottom line is that there is no one true way. A good idea is good in its context. Yet the core process is sound. When we listen well, collaborate, think deeply, and care about our work, the results are delightful.
Many thanks for this talk, it checked many boxes in my head :)
If you're working by yourself on a fairly small project then perhaps not abstracting your domain logic core from incidental complexity might work. But even then things change and the architecture needs to be decoupled and robust to support those changes. An RDBMS centric system mixes essential and incidental complexity and makes changes progressively more difficult. I'm working on just such a system right now and it's a nightmare. Clean architecture is about allowing friction-free changes by decoupling system components.
Where I come from, DDD stands for Davai Davai Deploy, which roughly translates as "Come on, deploy already!"
Needles to say, it's not considered the best practice, despite it's ubiquity.
😂
Everything you said is true, but it is also all in the book itself!
In several places it says that tactical design patterns are how DDD would be implemented in the 'OO world', but in other worlds like Functional or Relational patterns would be different, of course.
Regarding the 'UI world', its a bit different, as what you describe as UI being at the center of the attention is actually driving the model by the UI (most notably aggregate boundaries and service layer), which is completely and perfectly fine.
Maybe you are just interacting with a lot of 'Ortodox DDD' practitioners 😁 that interpret the book as the Bible instead of, as in your wonderful analogy, just a kitchen receipt for the main meat course!
If the dish is vegetarian, then we should use the Functional paradigm of course 😂
Antonmursid🙏🙏🙏🙏✌💝👌🇸🇬🇸🇬🇸🇬🇸🇬✌💝👌
Thank you for showing in a thoroughly manner something I'm advocating for so long: don't be dogmatic, take the theory and modify it to your needs to implement *your* version of DDD.
Excellent presentation.
if Scala and Functional programming was mentioned, I click "Like" :-) Seriously, I think DDD became like Agile some time ago, i.e. lots of consultants promoting it as a viable methodology that one can't live without it, however you can. I agree that DDD is something we used for years without knowing it is DDD. I try to avoid DDD jargon to be not locked in one methodology.
> I try to avoid DDD jargon to be not locked in one methodology.
That logic looks strange to me. "DDD jargon" gives you clear terminology for the certain concepts. Those word will be instantly understood by other people who are familiar with DDD, which makes communication more efficient. Why to forego the benefits?
@@xetas2 Lots of methodologies in the past had the same "feature" of trying to use the same "jargon" and most of them don't exist anymore, so, why DDD would be the savior at this time?
22 but not 34
@@RicardoSilvaTripcall why did SN15 land and previous iterations exploded? You're asking the wrong question.
amazing
The most important thing to focus on and nail down, IMO/E, after figuring out what the bounded contexts are, is how state changes in a bounded context. For this, domain events are really useful, especially in a more behavior-driven approach where you're defining the state changes through the window of behavior. That leads to some incorporation of UI: spelling out that setting a widget's color to red means that afterwards the widget shows up as red in the UI (UI for this could just be HTTP API; the key thing is making it clear what information has to be included). If you have invariants that need to be enforced, then that leads to distinguishing commands and events and to needing a consistency boundary: the actor model is pretty useful here.
Lll
Great talk. For me the problem is that many architects follow the common DDD patterns but ignore everything else. I find that many companies do Pattern Driven Design, where they mandate the patterns without caring what the problem space is. Some companies I have worked at force everyone to use specific "DDD" libraries and patterns, but nobody collaborates with business, there is no common understanding of the model and no shared language with domain experts. A context map is some drawing on the architects machine that nobody cares about. But they say they do DDD because they call their objects entities and value objects.
Mmmhhjjmip
A context already means that it's bounded. Otherwise it wouldn't be a context. Saying bounded context is just stupidly confusing.
How old is old?
it's hard to hear you. The volume is low and the sound is kinda distorted
Relational work makes a lot of sense when you are dealing with highly mutable data; and imply strong consistency; if it is replicated at all. Document databases make more sense when you need to replay events that created the data, so that lots of independent processors can respond; when actually altering things happens much less than adding new things. In those cases, strongly consistent islands, merged together with eventual consistency makes more sense. (ie: A replication log, where events need to commute to converge on a consistent result to handle partitions between the strongly consistent islands, etc.).
Qqqqa l@llfyyy
Very good talk! I kept telling myself it applies to Design Patterns so much to.
It's exactly what I think of DDD, especially when database design is overlooked due to excessive focus on implementing DDD patterns
this dudes's voice is LIT
I hope DDD is forgotten very soon, unfortunately DDD advocates never stay to see how unmaintainable system ends up to be or if they stay they don't admit it, Dieter Rams' 10 Principles of Good Design made me hate it from the moment I had to use it.
T
Isn't UX-driven exactly the hell we had in 90s with all those apps developed from Form1?
After decades doing software development, I concluded that Architects are the bane of the industry. It's the role to which the most incompetent developers aspire, to ensure the demise of projects. This presentation confirmed it.
Design is overrated.
If DDD is overrated, then this whole talk is overtheoretized. I've been using DDD for more than 10 years, and now I can't see any alternative approach deserving my attention. Especially when it comes to the security of architecture.
"I can't see any alternative approach deserving my attention", Sounds to me like that is the problem. I like the agility that is suggested with DDD but in practice architects just mandate a set of patterns and forget about everything else that comes with DDD. So would you say that the DDD patterns are perfect for every situation? Would all software be better off if everyone only used that set of patterns and nothing else?
@@brandonpearman9218 Again, DDD is not only patterns, as it was mentioned in the talk and as it was mentioned in the comments here. Patterns are only one chapter of the book.
The blue book sets priorities, makes emphasis on things that matter, shows clear examples why. It is a whole tool box, philosophy, not just patterns. Personally, I have never seen such level of deep understanding of breaking down complex systems anywhere else.
@@snowy0110 yeah thats why i said "in practice". Most if the time the focus is on the patterns and nothing else, i think because its something which is easy to mandate on the teams. But the power of DDD is not the patterns. I would rather use everything else except the patterns, than just the patterns(which is how most do DDD)
@@brandonpearman9218 Totally agree with you
Red
Haha, DDD is overrated what a wonder! My problem with DDD, somebody should maintain all domain definitions, which in real word really hard job and believe me nobody wants to do that.
That's just sad
buzzwords ftw ?