STOP dogmatic Domain Driven Design

[@alexandrewerner8427]

Great video! I think the separation between tactical and strategic design is very important to understand DDD. It gives the correct 'feeling' that DDD is half an implementation of patterns to build software, and the other half a way of thinking, organize and filter knowledge about the domain and problems we are solving with the software we will build. Your content is gold!

[@CodeOpinion]

Agreed (obviously 😆). Thanks for comment and watching!

[@fabriai]

It is always so easy to fall into the trap of confusing the activity with the value it provides. Thanks a lot for the video!

[@CodeOpinion]

Absolutely!

[@marna_li]

Another important lesson from life is that it is OK to diverge from the patterns sometimes. The point is that the pattern guides you in developing you application more easily - it is not an exact manual, per se. And indeed, sometimes you do things without adhering to the patterns, for various reasons. That will impact a project, but it will happen, especially in an environment with little or no code review. We have to think about the immediate trade offs. How will your decisions affect future work?

[@marna_li]

For the reference, I am trying to establish a boundary between my Identity module and IdentityService dependencies. Is it worth it? It depends on the project and priorities of than. It is my hobby project so I care more about the overall progress, robertsundstrom/xamarin-forms-app/tree/identity

[@CodeOpinion]

Trade-offs are everywhere. If you're applying a pattern blindly, you're not doing yourself any favors because you have no idea what problem it's solving for you, which also has a cost.

[@keithnicholas]

Way back when the DDD book came out I went to Erics talk at OOPSLA and it was all about exploring the domain with a model and language, and lots of talk about refining the model for the domain and thinking about the model, very little about implementation.

[@CodeOpinion]

Kind of funny how we now have DDD code templates. Hopefully more folks realize it's not about the patterns.

[@LeutnantJoker]

@@CodeOpinion Yeah good luck with that. I just quit a project in which exactly this was the problem. It's the same problem you have with scrum. People enforce the meetings without having any clue what value they're actually supposed to provide: Communication. And that ends with situations where you cannot talk to people across a desk about an issue anymore because "no we need to discuss that in a daily". I'm so sick and tired of this that I sometimes wish no book on any pattern had ever been written. Those books were meant as collections of solutions to general problems that highly experienced software engineers repeatedly ran into during their career. Instead they're now used like religious texts by zealots that have no idea what the original thought process behind them was, or even what problem they were even trying to solve

[@GreatSot9629]

@@LeutnantJoker so true.

[@ohwii]

Damn, Player. great stuff. I admire people that explain difficult ideas easy even when it is sometime oversimplified. At least I can understand the overall idea. If I wanted to understand model Driven design or Bounded Context in detail I read the blue book word for word. Lastly, your advice in skipping to chapter four was the best I heard from the internet Computer Engineering Community in a long time. PS: I have to say many things (aggregate, technical and strategic ) are still obscure to me but at least I have focus now.

[@hoangthangcao7868]

Yes you are right, applying the DDD is really hard, we will take a lot of time to practice and understand it. If we want to apply the DDD, we have to take time to prepare our codebase and structure. However, when we understand, we will like it. There some pros and cons. Pros: - More communication and understand the business - Clean Architecture mindset - Easy to write unit test - Easy to maintain Cons: - More code - Take time to prepare the codebase - Complicated Solutions: - More code (After our codebase is stable, we can do the generate code. we can use some tools and make some script to do it) - Take time to prepare the codebase (We have to find some open source to research ) Final : - Start to learn the new thing is never easy. - We should apply DDD when we understand and practice - We should consider carefully which part applies DDD.

[@cheetah100]

When you focus on the domain you aim to build in brittleness and inflexibility. It locks business logic i to your application. But businesses need to be adaptable. When business conditions change they need to react quickly. Building business rules into the software sets it in stone. There is no way for users to modify them quickly. There is no way to know ahead of time what rules will need to change. The answer is to express such rules as runtime configuration, much like a database allows runtime configuration rather than having a database compiled against a specific schema. Hard coding business rules is the antipattern.

[@hoangthangcao7868]

@@cheetah100 Thanks, it's nice feedback. My team applied the DDD. We overcome some problems and difficult things the first time. Now we are really happy to maintain and scale the application. The Infrastructure always changes/updates, but our business rules still stable. However, we always consider carefully which part should be using DDD.

[@SimonCanJer]

About complexity and amount of code - there is a good proverb "'miser pays twice".. I think that revenues from expenses for additional IOD , DI&IoC, patterns of SOLID and GRASP rules will be much much valuable, than expenses for deep reengineering because additional microservice needed, or another messaging is suitable more

[@EdwardFlores]

this is great, I have been trying to explain exactly the same thing for years to colleagues and excolleagues... and for so many ppl ends all the time with extreme dogmatical views...

[@harrydoan]

Great point! Same here, I saw many developers approach the DDD in the way of "how can I implement it, is there any example code that I can follow". Or DDD is just simply about a pattern that has the Aggregates, Domain Models, Value objects... That means we over-focus on the coding & implementation to some degree to make it "look like DDD" in the book, and we forgot the soul of DDD is more about modeling our business domains, the bounded context, and the integrations between them. In my opinion, "Aggregates, Domain Models, Value objects..." are just tools to reduce the risk of "doing it wrong" when implementing domains, and we can flexible to decide the right tool when we understand the DDD concept. Without the bounded context and core domain. It's not the DDD anymore (perhaps in some scenarios It's a good design, but It's not the DDD)

[@CodeOpinion]

Well said.

[@ActualJosiahPreston]

I’ve seen several videos about DDD where it’s obvious the person either didn’t read or didn’t understand the blue book. Good job.

[@NomadicBrian]

Love your videos. I think you've really got your finger on the pulse with this topic. I instantly see value in the boundary context and aggregate canvases. I'm also happy to hear someone say that not everything that is suggested in Domain Driven Design ideology is absolute. For example placing business logic in your domain model aggregate. I find myself trying to squeeze tests out of an aggregate and it doesn't make sense to me. Is it that I'm dense or refusing to be open minded about it? No I just feel if we are building a micro services there will be plenty of opportunity to test constructors and objects that came out of the domain model and that there will be more context within a specific type of service.

[@stevep5759]

A million times this, awesome video. After applying the strategic patterns in our codebase the actual business unit boundaries became much more clear. We had bounded contexts, aggregates and repositories but no subdomains :) The tactical patterns help with local complexity within a component (command side or query side) by separating the business logic from infrastructure code.

[@CodeOpinion]

That's a good way to put it: help with local complexity

[@abbasamiri2781]

You're right, we should always consider the context. There is also an important thing in the context which is the use-cases. Domain Model would be designed to respond the use-cases needs.

[@rmbl349]

one of the few youtubers with a brain.

[@FabioAngela]

I second your words. I'd add that nothing is set on stone and there is no "right solution", it all boils down to a lot of variables to consider (team skill, manpower, etc...) Personally I feel like most of the talk and stuff around patterns applied to DDD are just noise that cause you to lose time trying to grasp theoretically concepts that you'll fail to apply to most of your real world scenarios (being it because of constraints like variables I said, or performance considerations, or because a pattern doesn't fit well in every scenario). Flexibility is important and should applied even when applying patterns, the important thing is to understand the problem and ponder about pros and cons of a solution, based on the dev team invariants (:P). The most important think is to understand your domain, as you said, and follow SOLID Design Principles. P.S. being curious and eager to learn is the top skill a developer should have IMO.

[@attainconsult]

oh I skipped this for so long thinking it was clickbait but it turns out it is spot on modeling the bounded contexts is really where it's at

[@CodeOpinion]

All substance on this channel 🤣. Glad you finally watched!

[@slyace1301]

Dude just found your channel, I am binge watching like crazy! Thank you!

[@CodeOpinion]

Thanks! Report back if you find/notice a thread and common thread between a lot of them!

[@zimcoder]

Nice video, loved the thoughts presented, hated the clickbaity and misleading title.

[@jaideepdass]

Thanks. Skipping the content of the video because of clickbait.

[@CodeOpinion]

I changed the title to Stop dogmatic Domain Driven Design. Better?

[@StefanSchade721229]

To be honest, I dislike the clickbaty title. Instead of reading half of the blue book, go for Vaughn Vernon's DDD distilled which indeed focusses on strategic design first. But if you start implementing, tactical design is a thing. I found Scott / Millet helpful. Blue book tactical patterns with a grain of salt, since Evans still had layered architecture in mind instead of hexagonal one - still a great text on the broader concepts. Thumps up for engaging anyways, interesting topic, but I disagree on the relevance of tactical patterns. Btw ubiquitous language is at the very begining of the book

[@CodeOpinion]

Is a better title: "I stop doing DDD you won't believe what happened next!". But in seriousness, if you watch some of my other videos, you'll notice I advocate vertical slices rather than layers. I do think the tactical patterns can be helpful, even though I barely use them. I will use Aggregates for defining a consistency boundary and if you're Event Sourcing, they are helpful. In regards to "ubiquitous language", I didn't even use the term in the video, because in my experience, people just generally don't understand a bounded context yet along how a ubiquitous language forms it. Hence the way I described language in boundaries. I do appreciate the comment. Thanks for taking the time.

[@Kiev-in-3-days]

What I do with coding or architectural concepts is understanding the core principles but only implementing them as long as they don't not make my code more complicated. Really, nothing beats simplicity. That why I don't use full frameworks anymore, stay away from OOP or tools (webpack, etc) as much as possible, and only use "soft" functionnal programming or "soft" DDD principles. I might be delusional but, while I know there are tons of better programmers than me, I also sincerely believe my code is cleaner than any code I have ever seen from any program.

[@alexandrefedossov9765]

Thats why "Implementing Domain-Driven Design 1st Edition" by Vaughn Vernon is such a good book to start with DDD: because he switched strategic pattern to the first place.

[@mohamedyamani8502]

Is it particularly the first edition or...?

[@buffdude623]

Agreed. We do a microservice architecture at my job, and we do DDD... but not in every service! Some of these services are dumb and dead simple - they handle one "domain", but they are not complicated enough to warrant full blown DDD. Some services are full of business logic - we utilize it there. Having a hard and fast rule to always utilize DDD just makes things more complicated, in my experience.

[@CodeOpinion]

Yes, often times there's services/boundaries at the edge that aren't the core domain, but are required. These can often be CRUD in nature because they are more of a setup/referential data.

[@dom6477]

Hello. You don't need to strictly use domain model to be using DDD. You can have bounded contexts that are simple and simply use a table model and others more complex which requires a more complex structure like domain model.

[@Gumitto]

It's about understanding the dependency. Basically, you can do strategic DDD without tactical one, otherwise - you can't.

[@loop8946]

I still have a lot to learn, just flashing back to an episode of stargate where jack asks daniel if he has a book that explains the book he just read ^_^

[@JULIANOHAZE]

Just found your channel and loved the content. Please, continue doing more videos. Cheers!

[@CodeOpinion]

Thanks! Appreciate the encouragement! 👍

[@Sousleek]

Absolutely true. I've seen people that just do noun-driven developement (yeah in microservices format) and have a repositories all over the place under the brand of DDD

[@brandonpearman9218]

Agreed, It is so common for a team to say they do DDD just because their code has some DDD jargon peppered in. When nobody on the team understands the domain, and there is no collaboration. I believe its all about a collaborative evolving domain model, regardless of the patterns used. Are you doing DDD if you are the only one in the team building the domain model? or if every person has their own idea of what the domain model is? "The model is the team's agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest. A model captures how we choose to think about the domain as we select terms, break down concepts, and relate them."-Eric Evans

[@CodeOpinion]

Great quote from Eric. It's all about understanding, growing your teams understanding and evolving the model. The focus on patterns has and debates on patterns has not driven anything forward imo.

[@ianokay]

Are factories only necessary in the case of constructing complex value objects, or encapsulating a place to translate DTO into Entities?

[@SimonCanJer]

No one thing should be dogmatic Content of any book, as well as any methodology should be expressible in shortest and very useful terms, otherwise, it becomes to be a thing, which works for itself. DDD for me is very simple (before entering into details of context bounds and other subjects)- do not mix business logic (WHAT you are doing) and infrastructure(HIOW you are doing). Business logic components should not be aware of how things are done, and where they are done, for instance, which messaging system is used,, how it is initialized, which data engine is attracted). A business logic object should continue working as-is, even it is moved to another process, communicated over Kafka, instead of SQS, uses TS databases, instead of relational Domain context and bounds are important really for complex business logic, but first of all, for me, business logic must be clearly defined in clear terms for business on the design, as well on the implementation stage., without even mentioning infastructure. Yes, it takes more code, but really simplifies things when extending, scaling and optimizing common architecture

[@BeekuBird]

Most business logic isn't meant to go in entities. That's an anti-pattern called "fat entities". Logic in entities is to ensure the entity is valid.

[@daretsuki6988]

I got the Evans's book for hundred bucks, though stuck on 100th page for a while, probably will skip to the 4th then :D

[@CodeOpinion]

It's not the easiest book to read but I do recommed jumping to the 4th part.

[@tommypauker2600]

Hi, I'm looking foreward to you publishing a book on software architecture, just like bringing your videos to paper including code examples. Are there any plans?

[@CodeOpinion]

Maybe one day!

[@codewithkashif]

Would you mind adding few videos around Event Storming

[@CodeOpinion]

Will do. I'll add it to the list!

[@codewithkashif]

@@CodeOpinion if it lies too low in your list then lets see if you can add a quick intro video on it in near future :)

[@pablocom]

Man what a great video, you nailed it

[@CodeOpinion]

Thanks for watching

[@rahulaga]

nice video !! do you literally mean to skip everything and start with part 4 of eric's book ?

[@CodeOpinion]

Yes. To me it's the most important part. Go back and read the beginning after though!

[@heimeshoff]

Eric Evans said it himself multiple times, the book should have been written in opposite order, or be two books from the start. Strategical DDD and tactical DDD patterns. Highly recommend watch: kzbin.info/www/bejne/d6OuZnahnslgqbs

[@raymondyoo5461]

Great Advice. Thanks a lot

[@farhadthepersian]

Quick question, how would you source control the DDD project. Same repo?

[@CodeOpinion]

Meaning repo per boundary? They can be, but don't have to be.

[@ordep1132]

Precisely posted. On Eric's book there is the the timeless knowledge (strategic DDD) and the knowledge that came from applying the former on that specific age with the available tools. Knowledge crunching leads to ubiquitous language that leads to bounded contexts and context maps. Great understanding with your domain. Nothing to do with OO and tactical DDD. I have some food for thought and a question. You said that it is ok to have anemic models when you know you are going on this direction. From my experience, the result is a solution full of Transactional Scripts (see Martin Fowler), it is straight forward and keeps the code base quite simple at first, but as your codebase grows it becomes a smell with constraints duplicates and hard to reason about a valid state of your system. Do you have other thoughts on that? Do you think it is the natural start and then refactor to a richer domain model? Great video again.

[@jwbonnett]

I removed repositories from my code years ago! Why would you abstract that away and cause more work for yourself when you can make your code more efficient.

[@washedtoohot]

Huh what do you use then?

[@jwbonnett]

@@washedtoohot The repository pattern is just a wrapper, the most efficient code doesn't implment wrapping. We just call the database higher up the chain. You may think that you have to edit lines of code in many different places (essentially what abstracted code prevents), most people would be wrong in asuming that and even if it did, it wouldn't make a huge difference in development time, though it does make a huge difference in cost on large scale applications! Creating that abstracted layer takes development time too! Remember the more layers the more complex, the more you have to manage it, the more you have to refactor code later down the line if you were to change something substantial. Having a good balance between complexity and easy to understand code is key here.

[@hexdump8590]

Hi Derek. I'm starting with DDD because of your channel :). Would you mind pointing me to any good books, courses, etc. that could help a newcomer to get into DDD?. From your video I understand that we always get attached too much to concepts, patterns, etc and in the end they are just tools that can be used or not and sometimes even broken. I have found these situations many times before. I prefer to learn more from the practical side of DDD and not only the theory. So, again, with these premises could you provide links, videos, courses to take off in the right direction?. Thanks!

[@CodeOpinion]

I really enjoy talks and videos (hence why I have this channel). Luckily I spoke at ExploreDDD Conference a couple years and was blown away by the content. Check out their KZbin channel that has pretty much every talk: kzbin.info

[@rammehar5531]

very nice explanation. I have a question how to create mapper classes and hierarchy classes with base class AggregateRoot and Entity e.g Account, SavingAccount, CurrentAccount, HealthAccount etc

[@peterpodgorski]

It's DOMAIN driven design. Have your system follow your domain. Everything else is tools to make that happen, but the tools are not the point.

[@unclelhix]

Another great video

[@CodeOpinion]

Glad you enjoyed it

[@rusektor]

Why mirroring video in the beginning?

[@CodeOpinion]

Wasn't intentional. Never realized it until I was editing. Not usually showing anything on the camera that's written.

[@gafarolanipekun1202]

great one. thank you

[@CodeOpinion]

Glad you liked it!

[@djscratchnsniff]

thanks for the video

[@tarreislam]

Finally my answer has been questioned

[@kokoloism]

I am with DDD since 2014 I even went to DDD immersion in Portland in 2019 Problem with DDD is that it is too perfect to be applied. Time of DDD is yet to come, but not now

[@CodeOpinion]

Not sure what you mean by "too perfect to be applied"? I think it's more about evolving a model, which means you're not going to get it "right". It's not being perfect but changing as you gain more insights. There is no perfect model.

[@kokoloism]

@@CodeOpinion Not perfect model, but perfect methodology. Sorry for being unclear. Theoretically we all should understand business vocabulary, communicate with domain experts and implement according to that language. But there is a reason why DDD is not so well accepted. I don't know why.

[@CodeOpinion]

My opinion on the reason "why", is because talking with people within the business, understanding the domain requires effort that most aren't willing or not in the position/allowed to do.

[@RoamingAdhocrat]

0:15 that's clearly Part VI, Cigetarts Ngised

[@Main936]

Does a title get more click bait than this ?

[@CodeOpinion]

"I stop doing DDD and this happened!"

[@crimsoncourt9354]

@@CodeOpinion Destroy Dick December?

[@jna5413]

awsome video!

[@CodeOpinion]

Glad you enjoyed it

[@sathyajithps013]

Great video.

[@LemonChieff]

I don't know what any of this means. But ok, I promize I'll stop. I don't know.

[@myth00s]

"Domain-driven design" is just an application of principles heavily discussed during 20th century philosophy of language and in the field of terminology. Interpreted term = uninterpreted term used in context

[@Airbone69]

Nice love it

[@sujenm1199]

Please do it with Examples the Era of just speaking is gone. Thanks Again

[@CodeOpinion]

You mean code examples? Not entirely sure how I would show a bounded context in code?

[@sujenm1199]

@@CodeOpinion HI Derek, thanks for looking into this sorry was out for some time. I have seen few examples which are quite good in bounded context (crane vs crane) what I was referring to was when you use your actors in comparison use some examples to highlight them like you said Anemic pattern, Anti Pattern, email aggregators, not having other project refrences in domain(some pictorial representations would make your explanations more easy to understand) I know all this stuff but target all level of audience as you have no disclaimer that this video is for beginners, intermediate or advanced. Any how I am good to watch more and subscribed

[@sujenm1199]

@B D if you understand it better, you don't have to think. You can just adopt and implement it 🙂.

[@sujenm1199]

@CodeOpinion see you can do a video on Orleans please, will be happy to know your thoughts about it. Thanks in Advance.

[@Xaminn]

DDD is an interesting name. It seems like my keyboardddddddddd got stuck

[@Xaminn]

But, I'm just upset because I got a lot of (dddds grades) in school. /shrug

[@RodrigoOliveira-cc3kc]

DDD = Discagem Direta à Distância Long Distance Call in Brazil 😁😁😁 Ok, it is nonsense here, but I couldn't resist 😂😂😂😂😂

[@genericperson8238]

Going to have to downvote for the title and feigning novelty. DDD has gaining traction lately again has mostly due to the idea of bounded context. Putting an emphasis on using DDD for functional decomposition is neither new, nor an unpopular opinion.

[@CodeOpinion]

Thanks for the comment.

[@xamoxer1]

😆 "to me", programming is not a lone wolf activity

[@jeffthejava1]

Frasier Crane

[@dzl82]

These KZbin comments became so useless. Where is skepticism?

[@cheetah100]

Stop doing domain driven development.

[@tuberklz]

or stop dogma altogether

[@ewr34certxwertwer]

Domain driven design... Or, "how to try to make software for stupid people who is uncappable to divide it into smaller pieces"

[@yaghiyahbrenner8902]

most of this stuff is just data politics.

[@SoneiiraGF]

👏

[@lucasterable]

Stop doing development.

[@Techiesse]

I really want to give you a thumbs up but that title ...

[@CodeOpinion]

As I've replied to others, it wasn't international to come across as clickbait. Apologize for that. I can't say any of my other videos have ever been criticized for that. When I come up with a video, I already have a title in mind. That's exactly what it was. Stop doing DDD as what most think it is.

[@TimSchraepen]

Noice!

[@DanelonNicolas]

oh man, that clickbait... ooooh loord why!?

[@CodeOpinion]

I can't say that any of my videos titles are clickbait. While I can see how this one can be viewed that way, when I created this video, that's actually the title I had in mind. It's not intentional. Look at any other of my videos for reference.

[@DanelonNicolas]

@@CodeOpinion already saw your videos. I like them. That's way this clickbait feed so bad. like being stabbed in the chest