Came back from the domain driven design book by EE with lots of questions. This talk really elucidated some of the elusive concepts in DDD with real life examples. Great talk
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!
Thank you . Your emphasis on concepts like Ubiquitous Language and Bounded Contexts is particularly valuable. One question I had: How might we balance the trade-offs between the flexibility of microservices and the structured approach of DDD in a rapidly evolving business environment?
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.
Good question. I would say an employee originates from one context. Maybe the HR context where a candidate becomes an employee after signing a contract. After that an event could be fired like 'Employee hired'. Other contexts could listen to that and use the same Employee id(as a reference) to create a consultant for instance in the sales context. If you want to have an overview of everything related to that employee you could group information of different bounded contexts, using the shared employee id.
@@paulvfc I like that answer it makes sense there would be one authoritative demand that others could key off of and I also like the thought about using Events the other domains can listen to if they want to do something about their version of employee
my 2 cents. An "employee" does not really exist "across" bounded contexts. If it does, is mostly by mistake or by some misfortunate language representation. So in the example with "employee" and "consultant", it becomes obvious that there has to be some aggregation of "pieces" ("employee", "consultant") which lives outside of these bounded contexts and (forcefully) puts the pieces together. Often these are just "reports", and since they are rather technical than business, not sure makes much sense to think of them as "bounded contexts" (maybe as support business context). As some others commented, there should be another talk (Paul? ;) ) reg. communication and translations (or not) between bounded contexts.
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.
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".
I think there’s a deliberate reason cause if someone think they already know encapsulation and you tell them to always favour it in domain driven design, it can mean different thing to different people.
for me this phrasing represents "intentional" encapsulation. usually when you're taught about encapsulation you're only taught about getters and setters. the concept of "tell don't ask" goes further
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.
Indeed Thomas, there are always tradeoffs. I would recommend agains using wrappers for everything. Some Strings that need validation and have some business logic are perfect cases in my opinion. Think about an IBAN (validated), and which you might ask the country code (substring). But wrapping a firstName in another object is not something I do. No validation needed, no extra logic, just code bloat.
@@paulvfc I understand your point. Given a typical OO language like Java it is a reasonable approach. Other languages offer different possibilities for the example you describe. For instance what I typically do: leave the email-address as a string, but instrument functions (at the contextual boundaries or where-ever you like) with spec validation that can be turned on/off using a flag, depending on the deployment env. This approach doesn't seem like a big improvement at first sight but *dramatically* simplifies nested data-structures that pass through domain functions. Plus the significant advantage that I can use whatever functions my language offers to manipulate Lists, Maps, Vectors, Strings and other primitive scalars to manipulate the data structures while they pass through my domain functions, leading to much less code. The shape and type of these structures are spec'ed in the appropriate time and place, enabling a leaner approach and more opportunities for generic function design because there are no "private domain language" classes to take into account. Check out Rich Hickey's talks for a more elaborate perspective on this matter.
i think verrification depends on the usage of the value object so that usage context has to handle verrification as it needs. it is wrong to put that logic in value objects in my opinion.
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?
Domain Driven Design is agnostic to a programming paradigm. It’s more of a design approach I believe. To take your problems and solution from the Enterprise world to software world. However, Object Oriented Design aligns with arguably all of its construct.
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.
It depends how you perceive those terms. For example when you're using Doctrine/Hibernate library in infrastructure on the side of repositories, there's always some validation and transformation into domain objects. Or for example we are checking tenant id in multi-tenant application for each received object even it's already handled by database itself. Just to be sure/to double-check that we're not receiving what we shouldn't receive.
Agreed. The repository has a dependency on DTOs such as Card, which is weird. Secondly, sometimes the validation depends on other entities. A single repository can't validation and transformation alone.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
for me this is the most clear talk about DDD. concepts well explained, thank you
Great talk, thanks. Maybe you could do a part 2 where you show more code examples of multiple bounded contexts interacting with each other.
Came back from the domain driven design book by EE with lots of questions. This talk really elucidated some of the elusive concepts in DDD with real life examples. Great talk
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!
A clear and crispy talk. Much appreciated
Awesome talk!! Really well-explained and well-paced. Thx a lot!
Thank you . Your emphasis on concepts like Ubiquitous Language and Bounded Contexts is particularly valuable. One question I had: How might we balance the trade-offs between the flexibility of microservices and the structured approach of DDD in a rapidly evolving business environment?
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!
Amazing lecture, thanks.
This is a really great lecture
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.
Good question. I would say an employee originates from one context. Maybe the HR context where a candidate becomes an employee after signing a contract. After that an event could be fired like 'Employee hired'. Other contexts could listen to that and use the same Employee id(as a reference) to create a consultant for instance in the sales context.
If you want to have an overview of everything related to that employee you could group information of different bounded contexts, using the shared employee id.
@@paulvfc I like that answer it makes sense there would be one authoritative demand that others could key off of and I also like the thought about using Events the other domains can listen to if they want to do something about their version of employee
my 2 cents. An "employee" does not really exist "across" bounded contexts. If it does, is mostly by mistake or by some misfortunate language representation. So in the example with "employee" and "consultant", it becomes obvious that there has to be some aggregation of "pieces" ("employee", "consultant") which lives outside of these bounded contexts and (forcefully) puts the pieces together. Often these are just "reports", and since they are rather technical than business, not sure makes much sense to think of them as "bounded contexts" (maybe as support business context). As some others commented, there should be another talk (Paul? ;) ) reg. communication and translations (or not) between bounded contexts.
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.
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".
I think there’s a deliberate reason cause if someone think they already know encapsulation and you tell them to always favour it in domain driven design, it can mean different thing to different people.
@@khajalieubarrie5088 That... is so meta. The ubiquitous language of programming itself.
for me this phrasing represents "intentional" encapsulation. usually when you're taught about encapsulation you're only taught about getters and setters. the concept of "tell don't ask" goes further
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.
Indeed Thomas, there are always tradeoffs. I would recommend agains using wrappers for everything. Some Strings that need validation and have some business logic are perfect cases in my opinion. Think about an IBAN (validated), and which you might ask the country code (substring).
But wrapping a firstName in another object is not something I do. No validation needed, no extra logic, just code bloat.
@@paulvfc I understand your point. Given a typical OO language like Java it is a reasonable approach. Other languages offer different possibilities for the example you describe. For instance what I typically do: leave the email-address as a string, but instrument functions (at the contextual boundaries or where-ever you like) with spec validation that can be turned on/off using a flag, depending on the deployment env. This approach doesn't seem like a big improvement at first sight but *dramatically* simplifies nested data-structures that pass through domain functions. Plus the significant advantage that I can use whatever functions my language offers to manipulate Lists, Maps, Vectors, Strings and other primitive scalars to manipulate the data structures while they pass through my domain functions, leading to much less code. The shape and type of these structures are spec'ed in the appropriate time and place, enabling a leaner approach and more opportunities for generic function design because there are no "private domain language" classes to take into account. Check out Rich Hickey's talks for a more elaborate perspective on this matter.
i think verrification depends on the usage of the value object so that usage context has to handle verrification as it needs. it is wrong to put that logic in value objects in my opinion.
Great Talk, Helpful.
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?
Domain Driven Design is agnostic to a programming paradigm. It’s more of a design approach I believe. To take your problems and solution from the Enterprise world to software world. However, Object Oriented Design aligns with arguably all of its construct.
Great Talk !!
👏👏👏
merci beaucoup a toi :))
Thanks
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.
It depends how you perceive those terms. For example when you're using Doctrine/Hibernate library in infrastructure on the side of repositories, there's always some validation and transformation into domain objects. Or for example we are checking tenant id in multi-tenant application for each received object even it's already handled by database itself. Just to be sure/to double-check that we're not receiving what we shouldn't receive.
Agreed. The repository has a dependency on DTOs such as Card, which is weird. Secondly, sometimes the validation depends on other entities. A single repository can't validation and transformation alone.
Hexagonal Architecture is dead and he doesn't know it. Hexagonal is a type of BCE, BCE is still king.