STOP dogmatic Domain Driven Design 

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!

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.

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.

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!

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.

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?

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.

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

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.

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.

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)

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

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

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.

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

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.

Great Advice. Thanks a lot

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

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.

one of the few youtubers with a brain.

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

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.

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.

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!

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

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.

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

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

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?

Great video.

great one. thank you

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

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

Would you mind adding few videos around Event Storming

thanks for the video

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 ^_^

Nice love it

Another great video

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.

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

awsome video!

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

Can you make a video about value object please..?

Man what a great video, you nailed it

Why mirroring video in the beginning?

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

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

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

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.

Finally my answer has been questioned

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.

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

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

👏

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

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

Frasier Crane

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

"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

Does a title get more click bait than this ?

Noice!

These RU-vid comments became so useless. Where is skepticism?

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

or stop dogma altogether

most of this stuff is just data politics.

Stop doing domain driven development.

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

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.

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

Stop doing development.