Practical DDD: Bounded Contexts + Events = Microservices
Вставка
- Опубліковано 5 лип 2024
- InfoQ Dev Summit Boston, a two-day conference of actionable advice from senior software developers hosted by InfoQ, will take place on June 24-25, 2024 Boston, Massachusetts.
Deep-dive into 20+ talks from senior software developers over 2 days with parallel breakout sessions. Clarify your immediate dev priorities and get practical advice to make development decisions easier and less risky.
Register now: bit.ly/47tNEWv
................................................................................................................................
Video with transcript included: bit.ly/2nK3xbJ
Indu Alagarsamy talks about the intersection of DDD as a software discipline with Messaging as a technology counterpart. DDD allows us to move faster and write high-quality code. When we start to use the technology of messaging to communicate between clean and well-defined bounded contexts we get to remove temporal coupling. We now have microservices that are built for autonomy from the ground up.
This presentation was recorded at QCon New York 2019: bit.ly/2KFk7SO
#DomainDrivenDesign #Microservices #SoftwareArchitecture - Наука та технологія
Thank you for a great presentation! "Stickies are cheap, coding is expensive".
She stumbles quite a bit. Yet the best talk I have seen on DDD. Fantastic!
Thanks Indu! A great presentation on DDD in context of different services interacting with each other.
Great talk, we are building an awesome Software by using DDD with CQRS and has been one of the most exciting projects in my entire life!
I judged too soon. And I am sorry for that.
You presentation was awesome!. One of the best on this matter actually.
Congratulations for this great talk! It's very comprehensively explaining the approach. 👏
Really a great talk. Never seen full video instead this one.
Finally I can visualize Bounded Context and what is DDD
Great talk, very clear, full of good ideas! Thank you Indu :)
how do you handle Auth in a async event driven way? you just notify of the session id if each account that logs-in to all services?
Amazing, thank you very much for such an informative and interesting talk. Didn’t feel like a 50 minute slog, was a good watch.
Really? could not bear 10minutes .. This is called "Reservations" in our country.
Great talk!!
Amazing talk!
good presentation. clear and practical.
Good talk. Nice tip on identifying boundaries of bounded contexts like transactional consistency. Towards the end, certain ideas are not very clear especially on making decisions on stale data, side by side aspect.
Actually, by the book, transactional boundaries should help you identify aggregates.
Excellent talk
For me, this talk picked up increasing amounts of momentum. I hadn't considered how temporal coupling affects scaling independence. If Service A makes a synchronous call to service B, B must have the same or greater ability to handle request numbers.
Playing at 1.5x speed... Good talk..
1.75 .. world well and kept my attention
Sagas? Because stories aren't epic enough? :)
Find out this presentation is very practical
Well, questionable content: modify description and a quantity on the product is not part of a transaction, strange statement. ... Context per team, where we know how teams are reorganized all the time, a domain context linked to teams, seems a bad practice, talking about business process, then taking examples of function behavior and then use a business rule instead of a business process, all of these are clearly different animals, ... confusing. And then command internal to the context versus event cross bounded contexts, really... a call to a CRM, from a BFF to create a customer via REST is a command and it is crossing bounded contexts. And then the bad example: "when an aircraft type is changed..." claiming when you see a when, it is an event, No... it is the beginning of a business rule. an aircraft type is changed is the event, and we need the then part to complete the rule / behavior. Not all of this is a business process. Process is a sequencing of tasks done by humans or systems and orchestrated with sequential or adhoc flows. We see after that around 20' where the process is going cross bounded context. Saga pattern ... Sorry madam but it is the only way to support long running transaction - process cross bounded contexts... This is the first time I comment on technical video, but I feel sad because the subjects are so important and EDA and DDD and microservices are the core of new business applications and microservice cloud-native app. Good part on the ubiquitous language applied to the code. She used all the good buzz and good subjects, but a lot of recommendations are completely wrong.
I can't believe I am still hearing rubbish about the definition of concepts like 'product'. If an organisation does not understand what a product is then they are in trouble. Go ask the CEO what he thinks. Everything shetalks about can be done by a junior data modeller. This DDD stuff has become a mantra that people parrot without questioning .
Tim Hosking Everyone is at a different stage in their software development journey. What is simple to you is something they haven’t heard or don’t yet understand. You should also know there is something other people are experts in that you haven’t learned yet. Don’t disparage where someone else is at on their career/journey as a developer.
On the contrary, if you think coming up with a unified, enterprise wide definition of a "Product" is a trivial idea, or something which can be definitively answered by the CEO, then you don't have enough experience in the field, or you're working with extremely simple enterprises.
For example, if I asked "how many products do we have", how would you answer it? Is it the number of things presented on your ecommerce site, as determined by the sales team? Is it the number of different SKU's in your inventory system? What about when your purchasing team goes and gets some new inventory which is slightly different from your existing inventory, because your vendor changed something. Is that the same product, or a different product? Can orders for two "different" products ever be fulfilled with the same inventory SKU? Can one product relate to multiple SKU's, and if so, how do you decide on which SKU should be picked at the warehouse to fulfil the order?
And that's one of the easier entities to define. Trying to define an apparently obvious idea like "customer" is even harder.
@@allmhuran the challenge of getting a common definition of a business concept is one that experienced data modelers and IT professionals have faced for many years. For me personally, it has been nearly four decades. It is also a challenge that less experienced people raise as an intractable problem. What Indu did was to show three different viewpoints or interests in a product: sales, inventory, and shipping; and the various characteristics of a product that are of interest within those organizational boundaries. Having many dimensions of a product does not make it difficult to define a product - they just add to the richness of the concept. For example, just because shipping is interested in the weight of a product, does not mean that the definition of product is now so difficult. The same goes for the issues you raise. I get that you might not want to expose all of these characteristics across all boundaries, but don't hide behind the richness of a concept to say that defining it is so very difficult. My point about asking the CEO is that someone who is used to operating across all organizational boundaries like the CEO understands that there are various interests, but that does not make it hard to define the thing. For an experienced data modeler it is just part of the job to bring all the characteristics of a concept together. Semantic modelers (read the book The Working Ontologist) are also used to doing this as well and to even work across organizations, so that language and semantic differences between organizations who exchange data can be resolved. Too often I am lectured by programmers who have little understanding of the tools and techniques that have been used for many years. DDD is not discovering anything new. It may be one way to deal with semantic differences and the partitioning of systems, but these things have been dealt with for a very long time.
@@lukeconner This is my point - there are people who have dealt with these issues for a long time. People who do not understand the issues or do not understand the history of the industry add nothing by exposing their lack of knowledge. We are not advancing as an industry, but seem to be regressing with each generation of new developers who come along. Knowledge and experience is not being passed on. If you can come up with some way to accomplish this then you will have done a great thing.
@@timhosking You seem to have missed the point of why I specifically asked how you would get the *count* of products. What you've described is a different set of predicates that different departments might care about, but what you've failed to address is that different parts of the business might consider an entities in such different ways that there are different *cardinalities* and *relationships* involved. You can't solve this problem by simply having different projections which expose different predicates to different stakeholders.
If you think a product is "easy to deifne", you should be able to give me a one-sentence definition. You should also be able to give simple answers to the questions I posed. Too often I am lectured by programmers who have little understanding of the fact that different aspects of the real world may contain features which entail strict logical contradictions when looked at from different points of view, such that while any one point of view is logically consistent, it is impossible to have an internally consistent structure that is universal, particularly when you may not have the legal right to redefine any particular domain - for example, when one of your domains is a vendor system, whose data model is the intellectual property of the vendor.
After 10 minutes in, she does not seem confident what she is talking about.