STOP dogmatic Domain Driven Design

hey everybody it's derek martin from codopinion.com if you follow some of my videos you know that i mentioned terms or concepts from domain driven design but i actually think you should stop doing domain your design and instead get the blue book the domain drone design book skip everything at the starting and jump to part 4 strategic design the reason i say stop doing domain drive design is really what i'm referring to is what most people perceive as domain drive design that they've really latched on to things like entities value objects repositories but what i think's more important is what's in part four of that book which relates to boundary context and context maps so here's some statements or questions or comments that i constantly see on the internet that i think sway people in the wrong direction so that ddd is only powerful when your business logic is complex i think it's more useful to me when you have a larger system complexity just inherently comes with that that you're supposed to use the repository pattern there's so much arguing about the repository pattern and this is proving my point about caring so much about these things and that you need to use factories to be creating any entities or value objects that's what's what the book demonstrates or that if you have no logic in your entities that's an anemic domain model which is an anti-pattern and while i can get behind this it's only an anti-pattern is if you think you're creating a rich domain model within your entities if you're not doing that and you know you're not doing that then it's not an anti-pattern and you can't have dependencies within your domain model while again this is a good concept especially if you're thinking about having your core have no dependencies in it sometimes you actually need to depending on what you're modeling and things like double dispatch aren't the end of the world how do i make an email address unique across aggregates this one has probably been questioned i don't know how many times and again just goes back to relating what i was just referring to so am i doing ddd right are you doing ddd right if you're concerned about those types of things that i just mentioned no i don't think you're doing ddd right to me doing ddd is about understanding your domain and modeling your domain finding the boundaries there's value in the patterns of aggregates which again form boundaries there's value in those tactical patterns there is but that shouldn't be the focus to in my opinion about when you're doing ddd just because you have repositories and entities and value objects that means that you have those that doesn't necessarily to me mean that you're doing ddd again focusing on the domain to me in boundaries is the most important thing about doing ddd so one of the great ways in my opinion to find boundaries within your system and to kind of define what a bounded context is is through language and i love this tweet by mel conway even though that's not what he was talking about his bounded context but this is october 29 2020 where he said when a politician greets you with how are you and a nurse greets you with how are you they are totally different questions even though they sound and are spelled the same but really what this is describing is context and that's what this slide i always use to kind of describe that is if i use the word crane without context are you thinking about in construction a crane or are you thinking about a bird without any context you have no idea what i'm referring to but in a real world example words do matter in the world of transportation that i'm in right now let's say that we have the concept of a vehicle well if you're talking about a vehicle to different people that interact with the system that you're building in that particular domain well there's different sub domains inbound to context within those so somebody in recruitment which is hiring people to drive the vehicles they care about different things they care about compliance and do you have a proper driver's license you have insurance and those types of types of things but if you're talking about somebody's in operations that actually has to get freight move from place a to place b when they're talking about say a vehicle they're not thinking of those compliance necessarily they're more thinking about a vehicle in terms of okay it's on the way to a particular particular pickup or it's on the way to a delivery for related manifests so in different places people care about different things and even though you have the concept of a vehicle it can live within different subdomains and mean completely different things to those people that use those systems again depending on their context to me defining boundaries are probably the most important thing to do yet the hardest thing to do and my analogy is you go into a very dark room and all you have is a little flashlight that you're pointing around you're seeing how high the ceilings are where the corners are and as you do it more and more you started from not having any idea what the room looked like to more and more idea and some visual in your head of what that room looks like that's what you need to do when exploring a domain it has to mean more value and you need to be doing this first before you even care about the building blocks of things like aggregates so i do think the tactical patterns like value objects entities and aggregates i created a video on aggregates about being consistency boundaries there's the keyword boundary again are really useful but to me again going at a higher level to really understand what the problem space is before you get to this level of concerning yourself with aggregates so here are a few resources that i think you should check out of links in the description and the first is the bounded context canvas so this is a tool for designing and documenting a single bounded context for context mapping there's this repo that has kind of a cheat sheet of all the different context mapping patterns and as well as a starter kit for miro which is a online whiteboard so you can get started creating your own context maps lastly i have to mention event storming if you're familiar with ddd at all you've probably heard of it so check out any of the talks by alberto brandolini on event storehopping they're well worth their time to watch them so if you're asking the question am i doing ddd well my answer is yes if you're understanding and then modeling the domain my answer is no is if you're not doing that and you're concerned with just the tactical patterns of value objects and entities while those patterns like aggregates have a lot of value they do i'm not saying disregard them however i think you need to be understanding a little bit more about what that domain is the language behind it before you can even go down that road to be using those tools to model your domain if you found this video helpful give it a thumbs up if you have any thoughts or questions make sure to leave a comment and as always please subscribe for more videos on software architecture and design thanks you

Channel: CodeOpinion

Views: 132,701

Keywords: Domain Driven Design, software architecture, software design, cqrs, event sourcing, software architect, microservices, event driven architecture, message queuing, microservice architecture, domain-driven design, domain driven design microservices, domain driven design bounded context, domain driven design eric evans, domain driven design interview questions, domain driven design book, domain driven design microservices exemple, domain driven design boook, Bounded context

Id: 8XmXhXH_q90

Length: 7min 17sec (437 seconds)

Published: Wed May 26 2021