6:22 example 7:38 drawbacks of the cargo system design 7:50 2 perspectives of software design 8:01 perspective 1: software deisigner 8:32 side-effect of the cargo system 8:43 combine complex logic with the database update violates the principle of separation of logic from updating state 9:08 another perspective: domain 9:58 more detail, 10:02 we cant always get such high level discussion 11:01 what we want is to be able to notice when this happens and to take a correct action 11:18 how would it affect the software as it exists 11:46 we have to find another way of dealing with 14:15 one of the principles of DDD: the LANGUAGE is very important 14:21 one thing I've noticed: *when we talk about the software, we don't use the same language that actually in the software*
"Which one is more useful?" - great question to use in an event storming session. It's conveying that modelling is about the usefulness of it for the problem being solved, not about the soundness of the model per se.
@@winter-survivor I recommend installing Video Speed Controller extension. It allows finer control over what TH-cam offers. I generally watch videos at 3x speed, this one I watched at 2.5x because I wanted to focus on it.
great talk. Thinking about the whole shipping example, the distinction between the legs, the stop and the itinerary it occurred to me that this is very close to the definition of a category in mathematics. A Category is a set of arrows and a set of points and two maps from arrows to points: start, finish: Arrow -> Point. Paths are then built out of compositions of arrows, with the empty path denoting the identity. So to map that language to the example we have: + points map to ports (or other stopping places, eg towns) + arrows map to legs + paths map to itineraries.
Iconic talk. l I really like the qualification of abstractions being useful if they are use-case based but can this be further qualified by "accumulative (permanent) use-based abstractions". For example, what we are modeling does have more temporary features but seemingly insignificant but more permanent features. You want your model to remain useful in the longer term, so modelling the more permanent use-case driven aspects as priority may be useful. With this abstraction modeling mindset, more priority would be based on those seemingly near-insignificant aspects of the abstractions as long as they were more permanent. I guess for example Amazon didn't really consider "books" to be permanent but rather they were creating the distribution architecture where books could later be replaced by anything. So the more "permanent" aspect is the delivery infrastructure Amazon built - not books. I love your talk so much - thank you :)
Why is it that I don’t recognise the essence of DDD when I hear other people than Eric Evans talk about it? To me DDD is very much about modelling the data most useful.
Thank you for the video, seems modelling is a fundamental part of the design, the meaning of things it depends on the perspective, the point of view of each team, standarize that no sure if it is possible, already solutions are out there, but no publicly open, to study, no reuse, if not start from scratch, make this sense , hope it.😅
My knee-jerk reaction is also to like legs better than stops, but it's very distracting how poorly he explains his concept of stops, making that solution unfairly seem way worse than it probably is. What's the definition of a stop? What's the "unload transport" member signify? I assumed it was a method since it's a verb, but then he starts talking about "portions" (huh? what are those?), so maybe it's a noun? Ugh. And then he chooses to talk about the leg solution very concisely before going into fine detail about the stops solution to get a laugh. Ok, well let me ask you: which fruit is simpler to eat? Pineapple - a tasty tropical fruit. Apple - an edible fruit of the species Malus Domestica from the Rosaceae family with more than 7,500 known cultivars and a genetic makeup consisting of 17 chromosomes and an estimated genome size of approximately 650 Mb. Boy, pineapples sure sound a whole lot easier to eat - you can probably just pick one up and take a bite.
I think you got the concept behind the examples so he made his purpose. The probe of that is you are right and for his purpose realism is a distraction like he said.
Before the 1 minute mark he apparently shows a quote on the screen that is not shown in the video, no pronounced in the audio, we are hinted it is about not being perfectionist in design and we are asked to keep it in mind throughout the talk. Anyone knows the specific quote or the source of slides?
Meanwhile, my first thought was, why choose either? It seems clear to me that an itinerary is a series of *cargo handling events* that come in several different flavours, but for the purpose of the talk can be reduced to loading and unloading. The issue with both the stop and the leg model is that they are trying to couple two such events into a single object, and I don't think that is correct.
Regarding the end: Why would you need to tie the new functionality to any specific data type? In the beginning, Evans emphasized the importance of separating data from functionality, so why not just keep them separate? This seems like a phenomenon that only happens when you restrict yourself to an OOP-exclusive way of thinking about problems, but most modern languages don't force you to do OOP.
You are using at a very reductionist description of what DDD proposes, but I get how it's "actionable" insights can be interpreted just as that. Have in mind that DDD is a set of guiding principles that presents tools since the code level (you may have heard about value objects) up to a strategical level (when designing teams around bounded contexts) - and doing all that by focusing on the core domain and having a shared view of the problem space with the domain experts. The usefulness of this might not be apparent for a simple CRUD system, but its invaluable when dealing with other complex ones.
seidenada I was expecting that this Video talks about Bounded Contexts, Value Objects, Aggregates etc. But I got this information now from somewhere else, thanks!
@@sticksen DDD is not about value objects, aggregates … It is domain model which is architectural business pattern. But there are next patterns which can be used in relation with DDD. DDD is about naming, bounded context, vocabulary. It is more than programming technique. It is development philosophy.
@@GammaStrobe Although it is tempting to use synonyms, using itinerary is better, if that is what people in the domain are used to. Leg/Stop are different from route. Leg is a part of route and stop is technically not part of route. There might be some business process between each unload and load at a stop. Depends on what problem you are trying to solve as he says :)
What's wrong with legs? It needs external logic to make sure that the end of one leg is the start of the next. You don't have that problem with the stops. Legs simply have redundant information causing this problem. I am not sure why the non-tech people have to speak the same language as the thing is the software, non-tech people still normally cannot understand how something will work. Also, non-tech people use different words to mean the same thing, are we supposed to create different aliases? Sounds more like a fad than an actual software development technique that works in practice.
Nothing is wrong with either solution. And probably there even might be a better solution if I asked you to think really hard you might come up with something like a route or itinerary. It's not even that point he's trying to make. The point is we need to speak a common language to prevent us from creating software that doesn't fit the problems and scenario's of it's users . We need to carefully and thus not carelessly compass potential future requirements without overcomplicating and overspecifieing so we can always keep on building software ;). And in order to do that we might use DDD and create a lot of models and shared definitions instead of inventing new. Having proper business alignment is great. And event storming is also a very good way to involve domain experts in the proces of defining possible solutions and spotting it's shortcomings upfront.
In the text he encourages fleshing out these nuances in language to find deeper insight into the problem. Work hard to achieve clarity in the language used between teams, and all of the sudden a developer knows exactly what a domain expert is explaining, or vice versa, with less or minimal ambiguity. If some thing or part of the language is unclear or inconsistent, work to make it clear and consistent. As a result, you will gain valuable perspective on what needs to (or could) interact with something else to provide a rich and meaningful experience to the user. The benefit of this is, as a developer, you become very good at distilling down information and abstracting out the patterns - an invaluable skill regardless of the domain. It might seem futile and pedantic, but this skill of effective abstraction is transferrable across every single domain. Its difficult to abstract a pattern out of something you don't understand, but with effective language, the domain experts can help you bridge that gap.
Is realism a distraction thou? Aren't abstractions real aspects / perspectives on reality? Even when we are experiencing the real world, like the picture of earth from moon, we are still bound by abstractions and perspectives. We never experience reality in total, the "real" reality we always experience it in abstractions.
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
"By choosing a model that is well suited for particular problem you want to solve, you can make the computation more simpler." brilliant.
6:22 example
7:38 drawbacks of the cargo system design
7:50 2 perspectives of software design
8:01 perspective 1: software deisigner
8:32 side-effect of the cargo system
8:43 combine complex logic with the database update violates the principle of separation of logic from updating state
9:08 another perspective: domain
9:58 more detail, 10:02 we cant always get such high level discussion
11:01 what we want is to be able to notice when this happens and to take a correct action 11:18 how would it affect the software as it exists
11:46 we have to find another way of dealing with
14:15 one of the principles of DDD: the LANGUAGE is very important 14:21 one thing I've noticed: *when we talk about the software, we don't use the same language that actually in the software*
Pmy no uno menh
Many thanks mate.
Thanks man, + nice indentation
many thanks!
best comment in youtube technical talks. Your indentation was genius. 😻😻💌💌💘💘💝💝💖💖💗💗💓💓
"Which one is more useful?" - great question to use in an event storming session. It's conveying that modelling is about the usefulness of it for the problem being solved, not about the soundness of the model per se.
Absolutely amazing. Finally a video on DDD with real business use cases and lots of novel ideas!! thank you!
24:33 "You don't know if you've really explored the space of possible solutions if you never come up with a bad idea."
play it at 1.5x speed
Good call.
@@MaximilianBerkmann l
2x
So I just lost half an hour of my life because I didn't came down here before start watching hahaha.
@@winter-survivor I recommend installing Video Speed Controller extension. It allows finer control over what TH-cam offers.
I generally watch videos at 3x speed, this one I watched at 2.5x because I wanted to focus on it.
great talk. Thinking about the whole shipping example, the distinction between the legs, the stop and the itinerary it occurred to me that this is very close to the definition of a category in mathematics. A Category is a set of arrows and a set of points and two maps from arrows to points: start, finish: Arrow -> Point. Paths are then built out of compositions of arrows, with the empty path denoting the identity. So to map that language to the example we have:
+ points map to ports (or other stopping places, eg towns)
+ arrows map to legs
+ paths map to itineraries.
If we think abstractly enough, pretty much everything in life turns into arrows and points. (Directed graph)
Iconic talk. l I really like the qualification of abstractions being useful if they are use-case based but can this be further qualified by "accumulative (permanent) use-based abstractions". For example, what we are modeling does have more temporary features but seemingly insignificant but more permanent features. You want your model to remain useful in the longer term, so modelling the more permanent use-case driven aspects as priority may be useful.
With this abstraction modeling mindset, more priority would be based on those seemingly near-insignificant aspects of the abstractions as long as they were more permanent. I guess for example Amazon didn't really consider "books" to be permanent but rather they were creating the distribution architecture where books could later be replaced by anything. So the more "permanent" aspect is the delivery infrastructure Amazon built - not books. I love your talk so much - thank you :)
This is THE best DDD talk I have ever heard.
What is the fuss about? Some uml-modeling and a little "philosophy" ?
@Oscar Bardrick such mundane things that many (most?) developers don’t really get?
Omigod when he fixed the mic! 😗👌
The annoying popping at the beginning had stopped around 7th minute.
It was a great talk.
Thanks!
"Realism" is a distraction...............wow amazed by this line...............
Xxx
I watch and feel a nostalgy: we developed a shipping company software 8 yrs ago. We did not know about DDD, but made it pretty not bad
because DDD is a useless fad, what you guys used is common sense.
@@debasishraychawdhuri I don't think it's a fad. It's just one of many methods/techniques to build software better.
@@debasishraychawdhuri Any tool can be abused.
@@debasishraychawdhuri looks like you haven't built anything outside simple REST application during the time of your comment.
Why is it that I don’t recognise the essence of DDD when I hear other people than Eric Evans talk about it? To me DDD is very much about modelling the data most useful.
Exact case for me
absolutely beautiful talk
3:30 he adjusts the mic....yes!
Thank you for the video, seems modelling is a fundamental part of the design, the meaning of things it depends on the perspective, the point of view of each team, standarize that no sure if it is possible, already solutions are out there, but no publicly open, to study, no reuse, if not start from scratch, make this sense , hope it.😅
For everyone watching the first few minutes I can tell you: The sound quality will get during the talk
My knee-jerk reaction is also to like legs better than stops, but it's very distracting how poorly he explains his concept of stops, making that solution unfairly seem way worse than it probably is. What's the definition of a stop? What's the "unload transport" member signify? I assumed it was a method since it's a verb, but then he starts talking about "portions" (huh? what are those?), so maybe it's a noun? Ugh. And then he chooses to talk about the leg solution very concisely before going into fine detail about the stops solution to get a laugh. Ok, well let me ask you: which fruit is simpler to eat? Pineapple - a tasty tropical fruit. Apple - an edible fruit of the species Malus Domestica from the Rosaceae family with more than 7,500 known cultivars and a genetic makeup consisting of 17 chromosomes and an estimated genome size of approximately 650 Mb. Boy, pineapples sure sound a whole lot easier to eat - you can probably just pick one up and take a bite.
I think you got the concept behind the examples so he made his purpose. The probe of that is you are right and for his purpose realism is a distraction like he said.
I also missed the part where Stop and Leg had different properties so I was very confused about their interchangeability not being equal.
Oh ! the legend himself !
Thank you mr Evans, very insightful talk.
we use this at work and I love it.
I enjoy the way he thinks
Before the 1 minute mark he apparently shows a quote on the screen that is not shown in the video, no pronounced in the audio, we are hinted it is about not being perfectionist in design and we are asked to keep it in mind throughout the talk. Anyone knows the specific quote or the source of slides?
Great talk, simple but essential!
Meanwhile, my first thought was, why choose either? It seems clear to me that an itinerary is a series of *cargo handling events* that come in several different flavours, but for the purpose of the talk can be reduced to loading and unloading. The issue with both the stop and the leg model is that they are trying to couple two such events into a single object, and I don't think that is correct.
You'll get detention for your impertinence 😅
Regarding the end: Why would you need to tie the new functionality to any specific data type? In the beginning, Evans emphasized the importance of separating data from functionality, so why not just keep them separate? This seems like a phenomenon that only happens when you restrict yourself to an OOP-exclusive way of thinking about problems, but most modern languages don't force you to do OOP.
Was the audio recorded on a wax cylinder?
Where is your book DDD 2016 edition?
dude, if you cannot explain simply, sorry you did not understand it.
1.5x is best
Great contribution...
It's all shits and giggles until the gd DBA says "We don't need an Itinerary table" and shuts your design down.
Do I sound bitter? 😉
What's gd?
@@DurgaswaroopPerla God damn
This is gold! Thanks!!
make the legs a pair of stops?
Nice!
Compose the leg with two stops.
not watching due to disabled voting. Why should I assume it's worth my time if you're afraid of downvotes?
Hmm, so what exactly is DDD now? Just using Class names that match the typical parts of a domain?
You are using at a very reductionist description of what DDD proposes, but I get how it's "actionable" insights can be interpreted just as that.
Have in mind that DDD is a set of guiding principles that presents tools since the code level (you may have heard about value objects) up to a strategical level (when designing teams around bounded contexts) - and doing all that by focusing on the core domain and having a shared view of the problem space with the domain experts.
The usefulness of this might not be apparent for a simple CRUD system, but its invaluable when dealing with other complex ones.
seidenada I was expecting that this Video talks about Bounded Contexts, Value Objects, Aggregates etc. But I got this information now from somewhere else, thanks!
@@sticksen DDD is not about value objects, aggregates … It is domain model which is architectural business pattern. But there are next patterns which can be used in relation with DDD. DDD is about naming, bounded context, vocabulary. It is more than programming technique. It is development philosophy.
ZefekKa of course it is also about the things I mentioned. It’s the Tactical Design.
Closer than it sounds. I think this Is a great place to start, towards feeling like you really "get" DDD :)
20 minutes in and I have no idea what he's trying to communicate. I thought he was a pro on communicating.
move the mic of your face pls (literally go back in the past and do that, thanks)
Does the concept really require a 57 minute video?
I played at 0.5 x
Let me save you 57 minutes of your life..."Name stuff properly"
Great, now instead od going to sleep i will think about container ships
how's it going 🤣
instead of leg/stop “route” fit better?
Itinerary is the object that has the legs or the stops, and itinerary is a synonym of "route"
@@GammaStrobe Although it is tempting to use synonyms, using itinerary is better, if that is what people in the domain are used to. Leg/Stop are different from route. Leg is a part of route and stop is technically not part of route. There might be some business process between each unload and load at a stop. Depends on what problem you are trying to solve as he says :)
Thanks a lot ...
Average DDD fan vs average DDD enjoyer
❤❤❤
Even Eric himself still barely understands what DDD is and what he is talking about.
Hey, I haven't watched it all the way yet, but is it really that bad, that of 60.000+ views nobody liked it? Let me be the first than :D
Nops, the counter of likes is just hidden.
Flat Earth
What's wrong with legs? It needs external logic to make sure that the end of one leg is the start of the next. You don't have that problem with the stops. Legs simply have redundant information causing this problem. I am not sure why the non-tech people have to speak the same language as the thing is the software, non-tech people still normally cannot understand how something will work. Also, non-tech people use different words to mean the same thing, are we supposed to create different aliases? Sounds more like a fad than an actual software development technique that works in practice.
Nothing is wrong with either solution. And probably there even might be a better solution if I asked you to think really hard you might come up with something like a route or itinerary. It's not even that point he's trying to make. The point is we need to speak a common language to prevent us from creating software that doesn't fit the problems and scenario's of it's users . We need to carefully and thus not carelessly compass potential future requirements without overcomplicating and overspecifieing so we can always keep on building software ;). And in order to do that we might use DDD and create a lot of models and shared definitions instead of inventing new. Having proper business alignment is great. And event storming is also a very good way to involve domain experts in the proces of defining possible solutions and spotting it's shortcomings upfront.
In the text he encourages fleshing out these nuances in language to find deeper insight into the problem. Work hard to achieve clarity in the language used between teams, and all of the sudden a developer knows exactly what a domain expert is explaining, or vice versa, with less or minimal ambiguity. If some thing or part of the language is unclear or inconsistent, work to make it clear and consistent. As a result, you will gain valuable perspective on what needs to (or could) interact with something else to provide a rich and meaningful experience to the user. The benefit of this is, as a developer, you become very good at distilling down information and abstracting out the patterns - an invaluable skill regardless of the domain. It might seem futile and pedantic, but this skill of effective abstraction is transferrable across every single domain. Its difficult to abstract a pattern out of something you don't understand, but with effective language, the domain experts can help you bridge that gap.
the sound engineer should be fired
受益匪浅
Aaaaasasa
omg ! fell asleep... twas like listening to my wife yap
Coughing into the microphone? Who taught you that? Will you teach us that too? And without apology in the end?
How are your kids? shower some love, focus on technology...
Is realism a distraction thou? Aren't abstractions real aspects / perspectives on reality? Even when we are experiencing the real world, like the picture of earth from moon, we are still bound by abstractions and perspectives. We never experience reality in total, the "real" reality we always experience it in abstractions.
Well, that is a rather philosophical discussion.
In the context of software, real / abstract has the "usual" meaning.