Im just a simple software developer. When im not coding, i try my best to study concepts related to system architecture, design patterns. Hoping someday i'll be designing the architecture and implementation of a system. :)
Dude, where have you been all these years? Glad to see u here, finally.I just love the way you put every piece together. I can understand the hard work you're putting into this. You are doing a great service to software community.Thank you so much. You made my life easy.PS: The branding, BGM and voice are too good.
Great series. The video I was supposed to watch for a course I'm taking was so hard to listen to that I was glad to find yours instead. You were so much more concise and easy to understand. Anyone looking for an easy to understand introduction to DDD should watch your videos.
Oh man I really loved this sentence you closed it up with! where did you take that from? I'll totally quote that out! The presentation design is spectacular, nice taste. The subject is great and very well summarized! keep it up!
Good stuff. I appreciate it. I may take a minor issue with your division of problem and solution spaces at the 12:00 mark. The essence of DDD is that ubiquitous language and context maps etc span the two domains.
thanks, this have been the most clear and complete video of MS introduction. by the way Do you offer some certification course? or can you suggest me someOne. I am architect integration in a global company of TELCO I would like learn deeply how implement micro services
🎯 Key Takeaways for quick navigation: 00:51 Strategic *Design and Contexts* - Strategic design in domain-driven design involves thinking in terms of contexts rather than objects. - Contexts are the settings that determine the meaning of words or statements, emphasizing the importance of context in design. - In the context of strategic design, everything needs to be thought of in terms of contexts. 02:15 Key *Strategic Design Tools: Bounded Context, Context Map, Ubiquitous Language* - Bounded context, context map, and ubiquitous language are essential tools in strategic design. - Continuous integration is part of the figure but will be discussed in detail in upcoming lessons. - Focus on understanding the significance of bounded context, context map, and ubiquitous language. 05:13 Building *the Domain Model: From Concept to Detailed Model* - Building a domain model involves understanding the core values, talking to domain experts, and finding patterns. - The domain model is a mental picture that evolves into a detailed model for each part of the domain. - Bounded contexts, represented by blue circles, encapsulate specific concerns within the overall domain. 09:42 Bounded *Contexts in E-commerce Example* - Bounded contexts illustrate how different departments in an e-commerce scenario have distinct perspectives on a customer. - Each department has its own domain model, ubiquitous language, and database within its bounded context. - Relationships among bounded contexts are depicted in a context map, defining how they interact. 12:37 Problem *Space vs. Solution Space* - Understanding the difference between problem space and solution space is crucial in domain-driven design. - In the problem space, domains are divided into subdomains, including core, supporting, and generic subdomains. - In the solution space, each bounded context has its domain model, and relationships between them form the context map. 14:23 Developers' *Role and Technology Agnosticism* - Developers' understanding of the domain is emphasized as a crucial aspect before coding. - Domain-driven design is a technology-agnostic toolbox, focusing on understanding the domain first. - The toolbox provided by domain-driven design remains relevant throughout a developer's career. Made with HARPA AI
Good for starting a project, disaster for long living ones, have you ever heard expression is not in the domain, ask your business if they like paying you for refusing to deliver what they need.
you make good videos, but why do you play music in the background? makes no sense this is a teaching video, people have to be focused on what they learn and music only distracts.
If I have to decide as a end user, this course is the most fabulous DDD course that I can find on the RU-vid. Sadly, when I explore into your channel, I only found one course. Hope you come back online soon.
What if, after the implementation of a feature, you realize that a term that you used (as part of ubiquitous language) is not well understood by the customers and you decide to change how you present the term to them (this has been the case a lot of times from my experience). What should one do then? Update the whole codebase to match the new term? Or just update the 2-3 references on the customer-facing UI? The first one is the consistent choice but based on the frequency it may not be maintainable down the line, e.g. too many time consuming code changes and variable renames for very little real product changes. I would love your feedback on this issue.
The Ubiquitous Language must be understandable by all the stakholders before the implementation, so, if you have this problem it's becaous the Strategical Dessign was inadecuated and you must to back few steps to correct this on the design part, and then, in the implementation part. If you have a flaw in your design, your implementation, maintenance and new features maybe a chaos in the iteration of the code.
@@SliderGNU your stakeholders and your target audience is not the same though. They may have a different understanding or preference of terms. And terms can be really important on the ux
