In the last week of this year, we are closing another full year of virtual Domain-driven design meetups with the last meetup. So grab your drinks (tea, lemonade or anything you want!) and come join with your DDD questions to this lean coffee! We all post topics we want to discuss and together we will get into dialogues, so bring us your knowledge and DDD questions and see you then!
The term “sociotechnical” seems to have gotten a bit or renaissance lately, which is a great thing given all the positive impact it has had on many organisations and their workers around the world over the years. It also seems to have gotten some traction outside the academic circles this time after being developed and pushed from there mostly using action research since its humble beginning in the post-war British coal mines. It is an entry into systems thinking for many, with its idea about joint optimisation of both the technical and social aspects of an organisation. A common example is setting up the team topology to match the service architecture in an attempt to cater for negative effects of Conway’s law. This is all well and good, but if we think about it, viewing the modern organisation as a sociotechnical system is a bit of a tautology; all organisations have social and technical elements that people deal with on a daily basis. As with systems thinking, the value of sociotechnical system design is more about perspective and understanding rather than any specific outcome. There is so much more to sociotechnical design than DevOps and team setup that we need in order to cope in our increasingly complex and hazardous “digital coal mines.” Disclaimer: This talk is a prototype and is loosely based on my lightning talks at DDD Europe 2021 and DDD Europe Open Space, with the addition of new learning of Emery's Open Systems Theory as a foundation for sociotechnical systems design. Hope this will be more of a common exploration of the topics than a pure lecture. slides: https://www.dropbox.com/s/eeylt3cafssuogp/Open%20Sociotechnical%20Systems%20Thinking.pdf?dl=0
Most people introduced to Domain-Driven Design usually start with the first parts of the book, a very tactical approach treating DDD as a programming discipline. Then people begin discovering the architecture ideas in it, telling DDD is more than code. That is where they get introduced to the more strategic approach. But tactical vs strategic thinking can quickly turn into a polarity discussion where one is perceived as more important than the other. But with any polarity, both have up and down-side, you cannot do the one without the other. But when do we invest in one, and when into the other? Join us in this collaborative modelling session, where through dialogues we can discover signals when either strategy or tactical is not helpful anymore, and explore heuristics together to move to the other side, keeping the balance, doing tactical AND strategic design when we most need it!
DDD is probably one of the most important ecosystems of the last 20 years of software engineering. Nowadays frontend applications are an important piece of software architecture. Nevertheless, Bounded Contexts, Aggregates, Anticorruption Layers are all well-known concepts that somehow are often not applied when building large and complex frontend applications. The purpose of this talk is to show how some of the DDD techniques are easily applied to Frontend engineering, resulting in more robust and evolvable codebases.
'Begin with the end in mind' - Stephen Covey 70% of transformation efforts fail, and they fail because they lack clarity. 8 people will have 8 understandings of problems and solutions. By breaking down a target outcome, we create clarity and converge. Outcome Mapping is the first activity in Flow Engineering, which arose out of the need for clarity before starting further mapping activities. Outcome Mapping has its own flow, from ideas and pains to methods, guiding you from desire to action. You can map outcomes whether you are starting, in the middle or in the home stretch. It's a great way to bring a group together to converge, and set off in the right direction as a team. In this session: * Why outcome mapping is a critical activity * You'll see how outcome mapping works * How to create your own outcome map * Outcome mapping outcomes :] * I'll also share similar and complimentary techniques to provide many options for future exploration.ddddd
Some will say that you shouldn't even try to tackle a system bigger than what a typical agile team can absorb; others will say that agile just doesn’t scale beyond the simplest of systems. Experience suggests that reality lives somewhere between these two extremes, but where, exactly, is the clear and present question. In this talk, we’ll first consider the dimensions of scale - complexity, risk, and time - and then explore the ways that agility works (and sometimes doesn’t). Along, the way, we’ll study contemporary approaches to scaling agile, and conclude with an examination of work yet to be done.
Check out the first part here: https://virtualddd.com/sessions/68 We will continue to pick up other approaches. Wardley Mapping is a great tool in the DDD practitioner toolkit. Use it to explore and define domains and bounded contexts, examine the implications of change, compare different strategic options, and design the team topologies needed to make them happen. But what are the most effective ways to use this highly effective tool in collaboration with others? There are several challenges with Wardley Mapping for collaboration and communication. What if people can't read or write maps? How far should you go to get an agreement on a map? And what about mapping that contradicts politics or authority? Join us for this hands-on session with Ben Mosior and Kenny Baas-Schwegler, where we will tour different ways of Wardley Mapping together and discuss their tradeoffs.
Do Software architects have a bad name? Why? What are your expectations, what anti-patterns you experience? What are you thankful for from your architects? Should you have a software architect in the team, or between the teams? Changing the world starts with thinking and sharing the reasons. We would like to discuss this conflict at our next meetup in this open discussion. Please reach out if you are a developer and you would like to participate in a constructive discussion. Until then: fire away, put your thoughts, stories, examples on this https://t.co/dMUUI4DH1S?amp=1 miro board Thank you!
Wardley Mapping is a great tool in the DDD practitioner toolkit. Use it to explore and define domains and bounded contexts, examine the implications of change, compare different strategic options, and design the team topologies needed to make them happen. But what are the most effective ways to use this highly effective tool in collaboration with others? There are several challenges with Wardley Mapping for collaboration and communication. What if people can't read or write maps? How far should you go to get an agreement on a map? And what about mapping that contradicts politics or authority? Join us for this hands-on session with Ben Mosior and Kenny Baas-Schwegler, where we will tour different ways of Wardley Mapping together and discuss their tradeoffs.
Cat Swetel gave a brilliant Technologist's Introduction to Epistemic Injustice explaining 'epistemic injustice'—what we know, how we know, and who gets to decide and influence our reality. There are two kinds of epistemic injustice: * Testimonial injustice; When someone is ignored, or not believed, because of their sex, sexuality, gender presentation, race, or, broadly, because of their identity. * Hermeneutical injustice; injustice related to how people interpret their lives. Join us in this session where Cat will do a short introduction on the topic, and after, we will talk about how this impact domain crunching. For instance, if we don't include software developers in requirements engineering, what is the impact? What if the software teams only allowed to build user stories and aren't part of the narrative for their building? And what about the exchange of narratives across the ecosystem, i.e. across domains. Do we have the hermeneutic resources to describe emergent behaviour across the system?