So, start with big picture eventstorming and probably process level of eventstorming and instead of software design level eventstorming use eventmodeling or just after big picture?
That’s an option. For beginners: Storming once for the roadmap, then modeling releases tactically.
An ideal setup would be the other way around.
The entire company is professionaly adept in event modeling and their domain so they have a large investment into event modeling boards, and use it for planning and roadmapping while the devs use it for architecture.
This team then does mini storms with each new feature or client to get domain knowledge to the team and onto the model fast.
Keep in mind the purpose of DDD is to constantly remode areas of the business implementation that the team misunderstood in the first iterations.
Without an iterative approach to projects, any kind of documentation to this degree will be a waste of time.
So, start with big picture eventstorming and probably process level of eventstorming and instead of software design level eventstorming use eventmodeling or just after big picture?
That’s an option. For beginners: Storming once for the roadmap, then modeling releases tactically.
An ideal setup would be the other way around.
The entire company is professionaly adept in event modeling and their domain so they have a large investment into event modeling boards, and use it for planning and roadmapping while the devs use it for architecture.
This team then does mini storms with each new feature or client to get domain knowledge to the team and onto the model fast.
Keep in mind the purpose of DDD is to constantly remode areas of the business implementation that the team misunderstood in the first iterations.
Without an iterative approach to projects, any kind of documentation to this degree will be a waste of time.