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?
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.
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
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.