Clarification Request: Domain Roles vs. Architectural Characteristics

[olwulff]

Hello

I would like to raise a question regarding the "Domain Roles" section of the Bounded Context Canvas. Upon reviewing the description, I find it somewhat unclear what "Domain Roles" specifically represent in contrast to established architectural concepts.

From my understanding, the description of Domain Roles appears to somehow overlap with the concept of architecture characteristics as described by Mark Richards and Neal Ford in the book "Fundamentals of Software Architecture". These characteristics define the driving forces behind architectural decisions, shaping the system's structure and behavior.

To provide more clarity, I propose aligning this section more closely with the idea of defining the top three driving characteristics, as outlined by Mark Richards in his Architecture Characteristics Worksheet. This approach could help clarify the intent of Domain Roles by explicitly focusing on the key characteristics that influence the bounded context.

Additionally, I believe it would be valuable to highlight that DDD does not inherently enforce an event-driven or microservices approach. The driving characteristics of a bounded context could also indicate that a layered architecture is a suitable choice.

Would you be open to discussing how we can refine this section to improve clarity and alignment with established architectural principles?

Looking forward to your feedback.