Upcoming Sessions

[Hands-on] Collaborating and Communicating with Wardley Maps
6th of May, 2021 - 19:00 CEST
[Hands-on] Collaborating and Communicating with Wardley Maps
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.
Level: intermediate
collaborative modelling
wardley mapping
facilitation

Past Sessions

[Fireside chat] How Epistemic injustice impacts Domain Crunching with Cat Swetel

[Fireside chat] How Epistemic injustice impacts Domain Crunching with Cat Swetel

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?

Level: Advanced
Inclusion
diversity
domain crunching
Epistemic Injustice
[Live coding] Legacy live coding with Dr. Carola Lilienthal

[Live coding] Legacy live coding with Dr. Carola Lilienthal

In this hands-on session we will us a small legacy example that contains all the monstrosities that we find in legacy today. We will use DDD to analyze and refactor problems such as: large entities that are used all over the system and how we could divide them into smaller entities that live in different bounded contexts, the lack of value objects and what kind of value object could be introduced, and an anemic domain model and how we can improve it towards a rich domain model. In this session you will tackle a messy piece of Java code. Please be there with a running IDE for Java and download Step 1 of the example beforehand from https://github.com/lilienth/ddd-banking-example.

Level: intermediate
legacy
refactoring
anemic domain model
java
[Fireside chat] Udi Dahan - Ask me Anything

[Fireside chat] Udi Dahan - Ask me Anything

Join us in this special fireside chat with Udi Dahan answering all your questions spanning from Domain-Driven Design, Software Architecture from SOA, event-driven, CQRS, Large-scale distributed systems, Saga Patterns, Event sourcing, microservices and anything in between. Ask your questions upfront or during the session! You can also already engage and see the questions that are already asked at this Twitter thread: https://twitter.com/UdiDahan/status/1349302917648568321

Level: intermediate
event-driven architecture
cqrs/es
event sourcing
long running process
process manager
bounded context
[Panel] Fostering autonomous teams with proper leadership culture

[Panel] Fostering autonomous teams with proper leadership culture

Domain-Driven Design is a lot about collaborative modelling, understanding the user's needs collaboratively to design and implement the best fitting model. We want the teams to do this as autonomous as possible, getting fast feedback and new insights into improving that model. At the same time, they need to stay aligned with the company goals and strategy and other teams. To ensure this alignment, companies hire managers and architects for that task. But what decisions should be made centralized, and what decentralized? What part of managing should be autocratic, and what should be participatory? Join us in a dialogue with Ellis de Haan, Marc Burgauer, Andrew Harmel-Law and Trond Hjorteland. We will discuss everything concerning the culture around autonomous teams. Patterns of anarchy, command and control decision making, architects as a job, the long going discussion of 'do we really need a manager' and can leaders be managers? And dive into the stratified systems theory or 'levels of work' by Elliot Jaques.

Level: advanced
Strategic design
leadership
culture
[Dialogue] Transforming business models in the pandemic with Zsofia Herendi

[Dialogue] Transforming business models in the pandemic with Zsofia Herendi

Those ones who know me they know that I'm a big fan of business modeling and business model innovation. I ran quite a few workshops in this topic, I really like how people come up with great ideas to disrupt a business model. In these pandemic times if companies want to survive they really need to think through how they can best align their business to changing needs because of the covid situation. They need to surface, they need to continue delivering value to their customers, but sometimes it is not that straightforward. I just have a few examples of recent business model innovation that I would like to share and I would also give some overview of business modeling and innovation in general.

Level: intermediate
Business model canvas
strategic design
Beyond the hexagonal architecture: Functional Core & ...

Beyond the hexagonal architecture: Functional Core & ...

There are a few ways to split and protect your domain code from the intrusion of the technical stacks and other IT fads. After having promoted Hexagonal Architecture during all those years, we would like now to show one of its alternative: the Functional Core (combined with Imperative Shell). This short live-coding session will show you what it is and how it articulates with a cool domain. Also, and following some recent twitter discussions with Alistair Cockburn, we would like to finish this evening debating what hexagonal architecture is really about... Join us in this session with Thomas PIERRAIN - co-organizer of the #DDDFR user group and co-founder of 42skillz, and Bruno BOUCARD - developer, trainer, agile coach and speaker.

Level: intermediate
Hexagonal architecture
tactical design
functional core
anti-corruption layer
[Panel] Relationship(s) between problem and solution space

[Panel] Relationship(s) between problem and solution space

One of the more confusing concepts in Domain-Driven Desing is that of problem and solution space. There has been a long debate on Twitter and the ddd-crew github: https://github.com/ddd-crew/strategic-architecture-building-blocks/pulls?q=is%3Apr+is%3Aclosed People wonder how distilling the Core with the Core, supportive and generic subdomains fit and what space. What concepts are in the problem space, and what is the solution? And what is a precise definition of problem and solution space? Join us in this session are a diverse group of people spanning multiple disciplines to look at how they see the relationship(s) between problem and solution space in IT. And hopefully, in the end, we can have a useful, consistent model of those relationships between problem and solution space, core, supportive, generics (sub)domains for the #DDDesign community. With us will be: Dawn N Ahukanna Jabe Bloom Indi Young Nick Tune

Level: advanced
strategic design
UX
[Panel] Splitting systems towards bounded contexts and microservices

[Panel] Splitting systems towards bounded contexts and microservices

There are many reasons to split up large-scale systems towards more modular, smaller services with their own model and language. You can decouple teams and give full autonomy of that service to a team. By decoupling services and teams you can handle changes to the domain faster, having a faster time to market. You decrease the cognitive load of the teams, empowering teams to truly understand the complexity of their shared models with domain experts. But how do we split up large-scale systems? What are the characteristics we can dissect a bounded context? How do we split towards a microservices architecture? We do not only have to deal with shifting terminology here but also different rates of change in the business. Join us in this Panel where we will hunt for design heuristics to split systems towards bounded contexts and microservices. With us will be: Rebecca Wirfs-brock Chris Richardson Alberto Brandolini Nick Tune Krisztina Hirth Trond Hjorteland

Level: intermediate
essential
strategic design
software architecture
large-scale systems
Domain-Drinking Dialogues - 2020 ending Ask us anything party

Domain-Drinking Dialogues - 2020 ending Ask us anything party

Just before all the holidays start we are closing this year 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 Ask us anything party! We have invited several people from the community who will join an online fishbowl in a zoom webinar. You post your questions and we will discuss them. With us will be: Alberto Brandolini Krisztina Hirth Romeu Moura Evelyn van Kelle Trond Hjorteland Dawn Ahukanna Michael Plöd Zsofia Herendi Kim Koa Aminata Sidibe Marco heimeshoff Vladik Khononov Kenny Baas-Schwegler DDD Borat (Not the real Borat)

Level: beginner
essential
strategic design
tactical design
collaborate modelling
[Panel] What makes you a DDD'er?

[Panel] What makes you a DDD'er?

From twitter: https://twitter.com/mathiasverraes/status/1298665213978447873?s=20 Using collaborative modelling to build a shared understanding of your domain and use it to guide your design _is_ the philosophy behind DDD though. The rest is the principles, patterns, and practices. But perhaps just doing EventStorming does not actually make you a DDD'er, but what is? In today's panel, we will discuss with several people from the community what makes you a DDD'er? Joining us are: Emanuela Damiani Krisztina Hirth Mathias Verraes Jessica White Nick Tune

Level: intermediate
essential
strategic design
tactical design
collaborate modelling