Introducing DDD to a company is not easy, especially if you are new to DDD yourself. Following up from the Domain-Driven Design Starter Modelling Process that started describing a step-by-step guide for learning DDD. In this session, we want to extend and improve that process and see if we can describe a step-by-step guide from the inside-out. So what path do we need to take if you cannot start with the big picture strategic modelling? And what dangers lie ahead starting from the inside-out? If your team is your biggest constraint, how can we apply Domain-Driven design pragmatically? If you are new to DDD and would like help, or if you are experienced and would like to offer your advice, please attend this highly-collaborative session and share your ideas. We'll be working on Miro, the online whiteboard, for collaborating.
Decoding Paradoxes: Why are many good ideas in Software Delivery counter-intuitive
How does deploying more frequently improve quality? How does slack time in a team improve reliability? Why should we do it more often if it hurts? These are counter-intuitive concepts that don't make sense at first, and you'll be met with a bewildered stare...