I like that you kept this interview relatively short and pretty focussed. Such interviews often take much longer, like over 60 or even 90 minutes and also tend to touch so many subjects but only superficially. Needless to say, I don't enjoy those and usually don't watch them.
I agree with what has been already pointed out: you kept it focused and did a great job! I enjoyed the interview very much! I also want to add something to table. I think I can guess a reason why people actually focus a lot on the tactical part and aggregates rather than the strategic and domain modeling part. I can only reflect on my own experience and the ones of my friends. Developers are curious and want to learn new things but never or rarely have been or involved in the development of complex systems. All of the software systems I have seen so far did not really require a lot of domain knowledge. Most work was done on integration with other systems, CRUD, UI or artificial complexity with microservice madness. So there is little experience to draw from. And since for a more complex domain you will probably need a domain expert. Because you cannot train with them you focus on what you can do on your own, and these are the tactical patterns. Buy a book read it, think about it and tinker a little bit.
Domain experts existed for a long time, they were usually called, business analyst or SME (Subject Matter Experts), they usually worked along with the developer team, helping them to understand the domain, the context and also documented all the processes, but someone, for unknown reasons, decided that they were a thing of the past, but as everything in tech, it seems, we are coming full circle once again ...
I learned DDD after I was working on a side project in Go. It's an API with JWT authentication, subscriptions and a lot of other things. The project was getting a bit of a mess so I took a pause and learned DDD. I've been refactoring my project, and it's going well. The one thing I've learned as a solo developer is to thoroughly plan your side projects. Even if you're working solo, you can make use of DDD. As a solo dev I have to be the domain expert a lot of the time, because my clients don't really know what they want. I help them figure that out. I often spend weeks learning a customers domain so I can solve their problem. I wish there was more content focused on solo developers, because these enterprise level videos tend to focus on large teams of people. Thank you for this video, it's excellent.
It would be perfect to be able to spectate in one team that decides to start working in a DDD fashion after they have been working on an existing solution for a decade. To see how the deal with all the different opinions of team members, how you win the team over, what are the first obstacles, how to overcome them, finding the golden path how to translate all this theory into implementation.
Great conversation. I recently went to a talk at a conference. The speaker was talking about an approach to sync understanding between developers. A common problem is that developers get hung up on implementation. At the beginning of the talk they mentioned that developers can more often explain the "How", rather than the "What" and the "Why" for what they are developing. On top of that, everyone has their own view. DDD when practiced, using the proper tools in that context, might help you with transfer that understanding and to build a common picture that is not tied to the implementation.
Explore DDD exploreddd.com
Learn more about Software Architecture & Design by subscribing to my newsletter.
🚀mailchi.mp/63c7a0b3ff38/codeopinion
I like that you kept this interview relatively short and pretty focussed. Such interviews often take much longer, like over 60 or even 90 minutes and also tend to touch so many subjects but only superficially. Needless to say, I don't enjoy those and usually don't watch them.
That was the intent! Thanks for the feedback.
I agree with what has been already pointed out: you kept it focused and did a great job! I enjoyed the interview very much!
I also want to add something to table. I think I can guess a reason why people actually focus a lot on the tactical part and aggregates rather than the strategic and domain modeling part. I can only reflect on my own experience and the ones of my friends.
Developers are curious and want to learn new things but never or rarely have been or involved in the development of complex systems. All of the software systems I have seen so far did not really require a lot of domain knowledge. Most work was done on integration with other systems, CRUD, UI or artificial complexity with microservice madness.
So there is little experience to draw from. And since for a more complex domain you will probably need a domain expert. Because you cannot train with them you focus on what you can do on your own, and these are the tactical patterns. Buy a book read it, think about it and tinker a little bit.
Domain experts existed for a long time, they were usually called, business analyst or SME (Subject Matter Experts), they usually worked along with the developer team, helping them to understand the domain, the context and also documented all the processes, but someone, for unknown reasons, decided that they were a thing of the past, but as everything in tech, it seems, we are coming full circle once again ...
I learned DDD after I was working on a side project in Go. It's an API with JWT authentication, subscriptions and a lot of other things. The project was getting a bit of a mess so I took a pause and learned DDD. I've been refactoring my project, and it's going well. The one thing I've learned as a solo developer is to thoroughly plan your side projects. Even if you're working solo, you can make use of DDD. As a solo dev I have to be the domain expert a lot of the time, because my clients don't really know what they want. I help them figure that out. I often spend weeks learning a customers domain so I can solve their problem. I wish there was more content focused on solo developers, because these enterprise level videos tend to focus on large teams of people. Thank you for this video, it's excellent.
1
+1?
@@CodeOpinioni think he meant first 😅
you're right. 🤣
It would be perfect to be able to spectate in one team that decides to start working in a DDD fashion after they have been working on an existing solution for a decade. To see how the deal with all the different opinions of team members, how you win the team over, what are the first obstacles, how to overcome them, finding the golden path how to translate all this theory into implementation.
Great video as always. A guest I'd love you to have a conversation with is Steve Smith aka Ardalis.
DDD is modern approach to design the program model of the business ecosystem of the complex domains without a doubt
Great conversation. I recently went to a talk at a conference. The speaker was talking about an approach to sync understanding between developers. A common problem is that developers get hung up on implementation. At the beginning of the talk they mentioned that developers can more often explain the "How", rather than the "What" and the "Why" for what they are developing. On top of that, everyone has their own view. DDD when practiced, using the proper tools in that context, might help you with transfer that understanding and to build a common picture that is not tied to the implementation.