TIME: 6:32 END:6:35

"Are we missing something from DDD"

Question was about tactical: needed to load a collection of VO's from a repo This is about OUR domain: as DDD practitioners! Approach DDD as a domain we should learn collaboratively: on our day-to-day we advocate speaking to our SME's and collaboratively learning about our domain. This talk is about doing just that, in a "meta" way: speak about what worked for us, to learn about the domain of applying DDD

TIME: 6:35 END:6:35

It's a messy messy world out there

- There are a lot of problems a new team faces when trying to adopt DDD for the first time

TIME: 6:35 END:6:37

Which is just another way of saying: trust the requirements first before anything else

TIME: 6:40 END:6:44

The process will be: - Spend 5 minutes writing what you want to speak about on a sticky - Spend ~10 minutes Read the stickies and put one dot on the stickies you want to hear - We'll select the top stickies according to votes - The person who wrote the stiky will have to explain a bit - Other people can speak about their own experience regarding that, ask questions, etc This is an experiment. Let's try to see if we can all learn through participation. Maybe mention my experience to open up trust: - Lack of SME in PVA -> solved by focusing on boundaries to encapsulate complexity, making the aggregate as small as it could be, and having relatively aneamic domain models with PM's which use admin configuration to make decisions, pushing the decisions in.

Points of discussion in case of stalling - Lack of SME in PVA -> solved by focusing on boundaries to encapsulate complexity, making the aggregate as small as it could be, and having relatively aneamic domain models with PM's which use admin configuration to make decisions, pushing the decisions in. - Business causing god aggregates to appear: Business way too insistent on everything needing to be immediately consistent -> solution was to focus on the customer. async CQRS was introduced because it allowed us to be able to decouple processing and scalability of multiple services with vastly different behaviour and expectations (throughput, response times, scalability) - During Event Storming, the aggregate\BC boundaries were not clear -> pivot events, common terms in events with stickies being far apart (remember lack of SME's), re-use of projection by business logic resulted in aggregate boundaries. - Lack of trust in messaging, and eventual consistency caused too much reliance on end-to-end tests, which grew significantly, causing testing times to soar

DDD Fireside chat

What worked, what didn't, and what we did about it!

Timetable

About me

Inspiration

Even if we're not "missing" anything...

Things I wish I knew 8 years ago:

1. DDD is actually made up of a lot of principles and very few rules.

2. No matter the domain: someone already did most of the difficult parts. Probably by hand.

Types of problems

People problems

Strategic problems

Tactical problems

Format of this meetup

How does it work?

Hints - what to speak / ask about:

Feedback

Thank you