Residuality Theory and DDD - Cyrille Martraire and Barry O'Reilly - DDD Europe 2023

Domain-Driven Design Europe 2023
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
Residuality theory is a novel approach where the software architecture of a system emerges as a result of applying multiple stressors to the system. However, some seasoned software practitioners often design solid software architecture without knowing this theory.
We have reasons to consider that the heuristics from modern design approaches like Domain-Driven Design may well be congruent, to some extent, with what residuality theory would suggest. This talk by the author of the theory (Barry) and by a DDD long-timer (Cyrille) will explore the intersection between the two worlds, in a rigorous yet entertaining way.
Cyrille Martraire (@cyriux) is CTO and partner at Arolla (@ArollaFr), the founder of the Paris Software Craftsmanship community and a regular speaker at international conferences. With 20+ years of experience in startups, software vendors and banks, Cyrille still calls himself a developer. He's passionate about design in every aspect: TDD, BDD and in particular DDD.
Cyrille also has an extensive knowledge of capital market finance, and he's the author of the book Living Documentation published by Addison-Wesley Professional in summer 2019.
Barry is an Architect and researcher who has held Chief Architect positions at Microsoft, among others. He has also been a startup CTO, the Worldwide Lead for the Solutions Architecture Community at Microsoft, and founder of the Swedish Azure User Group. He is also a PhD candidate in software design and complexity science and the inventor of Residuality Theory.

[@joerndinkla]

Very interesting. Good explanations for someone knowing DDD. And funny. The walks remind me of the Gemba walks in lead manufactoring. But in traditional lean these walks are to get the information for structure, I guess.

[@Alex-qq1gm]

This is described as being totally new but how is it different from FMEA/FMECA?

[@Barry-ru9kf]

It’s entirely and completely different, and the relationship with FMEA is well documented in the articles on the subject. FMEA is a technical approach based entirely on components and defined specific failures, this looks at the entirety of the complex business system with a focus on criticality instead of correctness. If you can’t see the difference between this and FMEA is recommend reading the literature on both. I also think the article “It’s Just Like…” which is referenced in this very talk would be a good read.

[@Alex-qq1gm]

@@Barry-ru9kf thanks for the references will check them out

[@Barry-ru9kf]

Just to be clear - we still need FMEA once the design is arrived at!

[@jamison7762]

👊 'Promo SM'

[@skidkadda]

His English is so hard to follow. I bet he will have a lot of work in France, but around it not so much. Folks just won’t keep up with the bad speech and the pace in which it is spoken

[@cyrilleinparis]

I do my best :) And fortunately this doesn't prevent me from working abroad regularly 😊

[@bbravoo]

Sometimes you have to make a bit of an effort to get quality content. At least he talked in English. Had the talk being in French I wouldn't be able to understand. It is an European conference. People have accents. Even native English speakers have accents.