How do you foster a culture of learning and feedback among policy domain experts and developers?

My experience with an e-commerce company. For better defining the ubiquitous language, you need to kickoff a workshop that includes representatives from all relevant departments such as Sales, Marketing, Customer Support, Finance, Product Management, Development, and Operations to explore and map out the domain. Identify key concepts, processes, and terminology used by each department, collect terms and definitions used by each department through interviews, surveys, and collaborative sessions, hold review sessions with all stakeholders to validate and refine the glossary. Ensure that terms are clear, unambiguous, and agreed upon by all departments. After that, implement and enforce them, then review and collect feedbacks for improvements

I experienced as a DDD practitioner at a bank, I saw how differing interpretations of the term "transaction" led to confusion. Developers saw it as any software request-response cycle, while operations team viewed it as financial activities like transfers. Customer service interpreted it as any customer interaction. This ambiguity hindered effective communication. To resolve this, we established a ubiquitous language, defining "Financial Transaction" for money movements, "Service Transaction" for customer interactions, and "Technical Transaction" for software processes. This shared vocabulary bridged gaps between teams, enhancing clarity and collaboration in the banking domain.

From my experience, one of the best ways to start defining and discovering domain concepts to build a ubiquitous language is through Event Storming workshops. These sessions bring together the right people (stakeholders, developers, analysts, testers, and more) to discuss key terms, reduce ambiguity, and create a shared understanding. It’s essential to document these terms in a collaborative tool so everyone has a go-to reference. Keep in mind that the ubiquitous language will naturally evolve as the project progresses and as we learn more. So, be open to change and embrace continuous learning throughout the process!

Creating a bounded context canvas for boundaries gives good results for team members and stakeholders . We created bounded context canvas with inbound - outbound communication points ( users, systems , other bounded contexts etc) and business rules. It helps to organisation to see in one image and understand how it works with other systems and with different business logic. Also we realised that bounded contexts can be MVP of products too.

When you deal with the complexity of large domains, you need bounded contexts and context mapping. Some tips to create it are: - involve domain experts and developers in the context mapping process. - Consider creating context maps at different levels of abstraction. A high-level map can provide an overview of the entire domain, while more detailed maps can focus on specific bounded contexts - Utilize established integration patterns, such as shared kernel, customer/supplier, or anti-corruption layer, to guide the design of interactions between bounded contexts. - Keep the context map accessible and visible to the team. Use it as a reference point for discussions, decisions, and design choices.

Event Storming workshops are a great way to define and uncover domain concepts while building a shared language. By bringing together stakeholders, developers, analysts, testers, and others, these sessions create the right environment to discuss key terms, clear up ambiguities, and build a common understanding. This kind of collaboration doesn’t just make things clearer—it also encourages a culture of learning, where everyone is exchanging ideas and discovering new insights. As the language evolves with the project, it helps keep everyone on the same page and ready to adapt, continuously learning and growing together

The explanation of policy patterns as a way to manage domain-specific rules and decisions is insightful and offers a clear pathway towards more structured and manageable policy implementation. It could be beneficial to include examples or case studies illustrating the real-world application of these patterns. For instance, showing how a decision table is used in a financial application to determine creditworthiness, or how a rule engine manages complex business rules in an insurance application, would provide practical insights that help readers visualize how these patterns function in operation.