Writing cleaner code with Domain Driven Design by Paul van der Slot

I always thought that my code was fine. I took my time for naming things, wrote small classes/methods and tried to use other Clean Code practices. But after a job interview with a technical coach, I was pointed towards Domain-Driven Design (DDD) and some other design topics. I could learn a lot from it, said the technical coach. And I did! Since then, I started noticing how much parts of DDD could help with my day to day job. I will take you with me on my learning journey of Domain-Driven Design, and how it helped me improve my code. We will touch upon themes like Ubiquitous Language, Supple Design, Bounded Contexts and more. You can expect a talk with a lot of code examples and practical advise that you can use the next day.

[mirageman]

Great talk, thanks. Maybe you could do a part 2 where you show more code examples of multiple bounded contexts interacting with each other.

[surendardashinamurthy]

A clear and crispy talk. Much appreciated

[DomainDrivenDavid]

Very good, thank you! I am in the staring phase of understanding DDD and clean architecture, and I am implementing this on the next professional application I am working on!

[rodelias]

Awesome talk!! Really well-explained and well-paced. Thx a lot!

[Personal-M.I.S.]

This is good stuff! I've been trying to wrap my head around DDD for a while and some of this has really clicked. Skoal!

[thomas.moerman]

I would recommend against the use of derogatory of terms like "Primitive obsession" like it's some kind of accepted truth that using primitives is bad practice. It's not. For instance, there are a ton of cons to the "Wrapper obsession" remedy you propose: code bloat, superfluous indirection, the "private language" problem that DDD using OO typically suffers from.... There are always trade-offs.

[LarrySmith]

I'm interested in the following: once you decided that Employee is represented almost independently inside various bounded contexts, how can you later find out about an "Employee" ACROSS the bounded contexts? I get that they're different representations in each context but it still feels like in some situations there could be an implicit relationship of an entity across the contexts.

[chadlooker]

An "anemic domain-model" sounds more intuitive given that we write data-processing programs. The data outside the program is inert, e.g. the JSON you get over the wire or your row in the database doesn't have behavior. It makes more sense to me to model the data as data, and place what you do with the data somewhere else.

[johnathanwaters]

I may be misunderstanding, but is this basically a way to use ideas from functional programming in object oriented implementations, via the use of typing?

[stIncMale]

22:19 "tell, don't ask" - it's irritating when people keep coming with weird names for ideas that already have a name (I understand that this name was not invented by the speaker). This one, for example, is called "encapsulation".

[wazum]

Hm, there are multiple things wrong in this talk, e.g. Validation and Transformation in the (MongoDB) repository? Definitely not the right place for that.

[luisdanielmesa]

Hexagonal Architecture is dead and he doesn't know it. Hexagonal is a type of BCE, BCE is still king.