Explore DDD is designed for senior developers, team leads, and software architects - technical leaders with experience building software systems for complex domains. The conference provides a creative space where domain-driven design (DDD) explorers, enthusiasts and experts can connect and share real-world experience of applying DDD philosophy and techniques. Conference goals:
• Provide a safe, creative, high-quality, fun, learning DDD-centric environment for attendees. • Nurture a growing, diverse, pragmatic, humble, questioning, and open DDD community. • Spread knowledge and adoption of DDD more broadly amongst the general software development community.
Video production note - The camera feed unfortunately had focus issues during Xin's session. We've done what we could in editing to minimize the effect so we could still publish her wonderful talk. Thanks for understanding.
There are some temporary camera issues at the 6 min mark present in the original video feed (e.g. focus, visible cursor) that resolve after a couple of mins.
Never, ever, ever put commands in your event streams. You will *always* eventually rebuild your read-model by replaying events and if you put commands in there, you will be triggering downstream behavior.
That is to say the next time someone tries to view their Order Receipt, when you re-project their Order, you will CHARGE THEIR CREDIT CARD A SECOND TIME.
What a talk! 🎉🎉🎉 This is a must-watch talk for anybody following agile software development practices... Gomti... You spoke many stories from my mind too... 😊 Thanks a million for taking the courage to speak out, I really feel proud of you ❤️ This is inspiring me to keep asking questions 💗 like the way I do and don't feel bad about asking questions and pointing out improvement points, if any. I think it's not only me; these are shared experiences for software engineers (by the way, I hate being called a Software Developer, I believe I'm a Software Engineer) in this Agile software Industry. Thank you very much for sharing each of your stories connected to great references from Agile Manifesto or Eric's book. This is really inspiring to me. I've already added Eric's book to my reading list. You also mentioned good teams and bad teams - Yep, it's really correct - I also observed there are teams who work 💯 agile and succeed, whereas there are teams (who believe to be 💯 agile, fail hard and blame either agile or domains or architects or whoever they find they can put the blame easily to😂) I'm hoping to connect to you professionally to learn more from you and talk about shared experiences and your learnings out of it.... 😊
Watching Mr. Scott Wlaschin talks are just pure fun. And of course learning a lot about the content but also gives incredibly inspiration how to explain it to other people in a very didactive way. Being tolerant for other choices but point out why this choice in particular is a better choice. I really like this and thanks for the great work.
by doing pure events(not orchestrator) nobody know what going on. down the road what will happen. what if there is one more step between finance and shipping for example: fraud detection - now you need to change the shipping to not listen to finance and reservation any more instead listen to fraud detection
Thanks for the comment. Yes, that's correct in a distributed system one of the biggest disadvantages is that it's harder to get an overall picture of what's going on. On the fraud detection part, it really depends on how it's implemented. Fraud detection could be implemented the way you suggest or by changing only finance. Finance "invokes" fraud detection as part of the payment flow and only if everything is fine publishes the event that eventually triggers shipping. In such a way shipping remains unaware of the fraud detection step.
Could someone explain me, how the information of quantity would change in the services? From my understanding, when Sales is the owner of the "shopping cart", and the quantity changes, it needs to publish an "QuantityChanged" event to notify the other services of the system, right?
It doesn't have; As suggested, when a command to update quantity is fired from client, and view-model decomposition occur, warehouse service will pick that command and behave according to it, so sales remain out of picture here.
Thank you for this excellent introduction to DDD and F#. 00:08 Title 00:10 How many things are wrong with this design? 01:09 The intersection between Functional Programming and Domain Driven Design 01:20 Is Functional programming scary? 02:01 Is Object Oriented programming scary? 02:42 What is Functional programming good for? 03:28 Part I: The importance of design 16:20 Part II: Understanding FP type systems - An introduction to "algebraic" types 25:19 Part III: Domain modeling with composable types - What can we do with this type system? 25:32 Modeling optional values 29:00 Modeling simple values and constrained values 36:38 Replacing flags with choices 42:16 Part IV: Encoding business rules with types 44:39 Communication is two-way - It's OK to push back 45:49 Summary
"Inject a smarter thing" is the best "slogan" I've heard in ages. It makes more sense of dependency injection than any other explanation I think I've ever heard. So,,, The Viceroy Butterfly is a test-mock! ;)
The last part of this video is very important. Sometimes you see something very elegant and you say "I don't know what this thing does.". You don't need to know it, you trust it as long as the test works. The test need to be simple and also elegant that does not break in smallest change as well so it is meaningful If there is no test, then your argument is valid that you can't be sure that it still works OK. You learn what that thing does by looking at the test. if the test doesn't change, the source code change and it still works, no problem then. The main problem is, and happen many times, we skip the test in favor of short dev time..and then it bites us back in the ass later down on the road
Hi, SNAP-E stands for Snap Not Analysis Paralysis - Enhanced. Boris diagrams tend to look like spider webs, so it is named after a song by The Who called "Boris the Spider"
Thanks Mauro, great talk! And thanks for this "stupid question technique", I used by myself similar technique, but it was my "idea" and I was not sure it makes sense at all, thank you for confirming!!! And I want to stress that some stupid scenarious can be reality!! Concerning your example - it was actually real situation when requirements were ''if the last name end at xx give a discount % to the customer" and it was a kind of action - every day anothe last name gets a discount)))
The guy resembles a retired rock star. Keeps playing same tune and expects to make money of it. But if someone wants to remain in the focus of attention, there is no way around creating NEW content.
Great talk, great book! The concepts have a ton of value even if you don't use F#. It's also a smooth beginner-friendly introduction to domain-driven design.
`People will not self-organize around a system that they do not understand.` That is a good thought to keep in the back of the head when trying to navigate things like this.
Clear, easy takeaway: Turn conditionals into polymorphic objects so that you can just send messages, while having the detailed behavior all stuffed at a different level.
Essential talk for developers. It well deserves all upvotes, also the zero downvotes speaks for itself. Not that many other videos has an infinite upvote/downvote ratio on RU-vid :)
A lovely talk. Thank you. I'd add that compile-time type checking isn't like having microtests, but rather that they are microtests. Specifically they are microtests that most programmers would not volunteer to write and that they fortunately cannot forget to run.
How does placing an order then work? does the information in each boundary transition to its own order model? I could assume sales would be the one where this operation takes place, but how does validation in other services regarding the placement of this work? e.g. you could call sales to say place this order/order this cart, but what is there is a business rule for an order can only be placed if all of the items have stock at that time? Thanks
Hi Matthew, thanks for the comment and more importantly for the patience. Unfortunately, there is no way to get notifications for comments on RU-vid videos not uploaded by me. Back to your questions: > does the information in each boundary transition to its own order model? Correct. > I could assume sales would be the one where this operation takes place, but how does validation in other services regarding the placement of this work? e.g. you could call sales to say place this order/order this cart, but what is there is a business rule for an order can only be placed if all of the items have stock at that time? Sales can have a saga that waits for confirmation events from other services before proceeding with the order. The most common use case being waiting for Payments to raise an event confirming the authorization on the user's credit card, for example. I wrote about some of these topics on my blog: - milestone.topics.it/view-model-composition/2019/04/18/the-fine-art-of-dismantling.html - milestone.topics.it/2019/05/02/safety-first.html Let me know if that answers your question. Do not hesitate to get in touch, the best way is to use the contact form on the blog. Cheers.
