What is DDD - Eric Evans - DDD Europe 2019

[@ruixue6955]

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*

[@Gatiguay]

Pmy no uno menh

[@5uperM]

Many thanks mate.

[@garygao4863]

Thanks man, + nice indentation

[@yilai6307]

many thanks!

[@neoflyboy]

best comment in youtube technical talks. Your indentation was genius. 😻😻💌💌💘💘💝💝💖💖💗💗💓💓

[@scottsoward]

"By choosing a model that is well suited for particular problem you want to solve, you can make the computation more simpler." brilliant.

[@seidenada526]

"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.

[@augustsbautra]

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."

[@pr0l0gix]

Absolutely amazing. Finally a video on DDD with real business use cases and lots of novel ideas!! thank you!

[@hologos_]

The annoying popping at the beginning had stopped around 7th minute.

[@ahmadmusaffa]

It was a great talk.

[@simasbutavicius8485]

Thanks!

[@cooperating.systems]

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.

[@pyepye-io4vu]

If we think abstractly enough, pretty much everything in life turns into arrows and points. (Directed graph)

[@786gnafis]

"Realism" is a distraction...............wow amazed by this line...............

[@fdfdfhdg9554]

Xxx

[@EdwardLangeland]

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.

[@abhinavpaudel1152]

Exact case for me

[@jeet.prakash]

This is THE best DDD talk I have ever heard.

[@anderssyvertsen7791]

What is the fuss about? Some uml-modeling and a little "philosophy" ?

[@EdwardLangeland]

@Oscar Bardrick such mundane things that many (most?) developers don’t really get?

[@thiagovilla970]

Omigod when he fixed the mic! 😗👌

[@mamaladka]

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

[@debasishraychawdhuri]

because DDD is a useless fad, what you guys used is common sense.

[@pieter-janliekens9306]

@@debasishraychawdhuri I don't think it's a fad. It's just one of many methods/techniques to build software better.

[@lionelt.9124]

@@debasishraychawdhuri Any tool can be abused.

[@bharathmshetty]

@@debasishraychawdhuri looks like you haven't built anything outside simple REST application during the time of your comment.

[@kingscrusher]

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 :)

[@marredcheese]

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.

[@augustosotelo5914]

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.

[@elysedawson8274]

I also missed the part where Stop and Leg had different properties so I was very confused about their interchangeability not being equal.

[@Inbarreto]

play it at 1.5x speed

[@MaximilianBerkmann]

Good call.

[@rsardenberg]

@@MaximilianBerkmann l

[@RicoMinovo]

2x

[@winter-survivor]

So I just lost half an hour of my life because I didn't came down here before start watching hahaha.

[@Ascentyon]

@@winter-survivor I recommend installing Video Speed Controller extension. It allows finer control over what KZbin offers. I generally watch videos at 3x speed, this one I watched at 2.5x because I wanted to focus on it.

[@esteban-alvino]

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.😅

[@darwinschuppan8624]

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.

[@Anon-xx9qc]

For everyone watching the first few minutes I can tell you: The sound quality will get during the talk

[@pietropeterlongo2695]

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?

[@150metri]

3:30 he adjusts the mic....yes!

[@carnaedy]

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.

[@Ade-nn]

You'll get detention for your impertinence 😅

[@bishalneupane]

absolutely beautiful talk

[@TricoliciSerghei]

Thank you mr Evans, very insightful talk.

[@souravnandi7705]

Oh ! the legend himself !

[@sortof3337]

we use this at work and I love it.

[@matt-g-recovers]

I enjoy the way he thinks

[@zuxionglin4092]

Where is your book DDD 2016 edition?

[@cynew]

Great talk, simple but essential!

[@TheZimberto]

Was the audio recorded on a wax cylinder?

[@janeknox3036]

20 minutes in and I have no idea what he's trying to communicate. I thought he was a pro on communicating.

[@FaustoOliveiraFilho]

make the legs a pair of stops?

[@sticksen]

Hmm, so what exactly is DDD now? Just using Class names that match the typical parts of a domain?

[@seidenada526]

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.

[@sticksen]

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!

[@ZefekKa]

@@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.

[@sticksen]

ZefekKa of course it is also about the things I mentioned. It’s the Tactical Design.

[@robmoore2209]

Closer than it sounds. I think this Is a great place to start, towards feeling like you really "get" DDD :)

[@simonoreilly2k9]

Does the concept really require a 57 minute video?

[@EdissonReinozo]

This is gold! Thanks!!

[@isparoz]

dude, if you cannot explain simply, sorry you did not understand it.

[@thatpaulschofield]

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? 😉

[@DurgaswaroopPerla]

What's gd?

[@thatpaulschofield]

@@DurgaswaroopPerla God damn

[@MichaelMeierhoff]

Great contribution...

[@phyzix_phyzix]

Compose the leg with two stops.

[@lightfeather9953]

not watching due to disabled voting. Why should I assume it's worth my time if you're afraid of downvotes?

[@ewamagaj7312]

Great, now instead od going to sleep i will think about container ships

[@chandrasekharanem1155]

how's it going 🤣

[@RH-of5cr]

move the mic of your face pls (literally go back in the past and do that, thanks)

[@shawnkec]

Nice!

[@MS-cs7gt]

1.5x is best

[@montancheg]

Even Eric himself still barely understands what DDD is and what he is talking about.

[@ashw6015]

Let me save you 57 minutes of your life..."Name stuff properly"

[@m313shaikh]

instead of leg/stop “route” fit better?

[@GammaStrobe]

Itinerary is the object that has the legs or the stops, and itinerary is a synonym of "route"

[@sriramvenkatakrishnan4482]

@@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 :)

[@Guzguz28]

❤❤❤

[@1testrad]

Thanks a lot ...

[@ak-yo4wo]

I played at 0.5 x

[@IDesireToUpliftOthers]

Average DDD fan vs average DDD enjoyer

[@Mvrck44]

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

[@eduardojreis]

Nops, the counter of likes is just hidden.

[@debasishraychawdhuri]

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.

[@pieter-janliekens9306]

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.

[@adamcarrol2049]

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.

[@ivanrodriguez9427]

Flat Earth

[@李蛋球]

受益匪浅

[@davidhosking4674]

Aaaaasasa

[@godisnjiodmor]

Coughing into the microphone? Who taught you that? Will you teach us that too? And without apology in the end?

[@hydtechietalks3607]

How are your kids? shower some love, focus on technology...

[@nodetransit]

omg ! fell asleep... twas like listening to my wife yap

[@HR-qy3gf]

the sound engineer should be fired

[@alihammadshah]

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.

[@pyepye-io4vu]

Well, that is a rather philosophical discussion. In the context of software, real / abstract has the "usual" meaning.