Virtual Domain-driven design

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. This podcast is the recording of our open discussion with the community.

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?

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.

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.

The podcast discusses the benefits of splitting large-scale systems into smaller services and the challenges of dividing systems into bounded contexts and microservices. They explore topics such as considering the human factor in software development, implementing data entities, finding service boundaries, challenges of splitting systems and modernizing legacy code, functional decomposition anti-patterns and event storming, different concerns and collaboration, value configurations and modeling a value mesh, and the next trend after microservices.

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.

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

There has been a lot of fuzz around the topic of test-driven development; some find it useful; some don't see any value in it. You also have different flavours like Detroit being inside-out, or London going from the outside-in. And then you have people saying TDD is about testing or is it a design tool? In this session, we will talk with Dave Farley about all these topics, and especially how to use TDD as a design tool. Dave Farley is well known in the software community, especially being the co-author of the continuous delivery book. He is also a firm believer that Test-driven development is one of the core principles to do proper continuous delivery.

The recent COVID-19 pandemic forced us DDD practitioners to move our collaborative modelling efforts to the remote world. Within collaborative modelling, we want to share all the information we have, all the different perceptions, even if they might look weird, quirky or invalid at the start. Only then can we design and create enriched models to build sustainable and valuable software. The problem here is, people will only share all their information if there is psychological safety, and that is already hard in a physical session, let alone remote.