I'm still in my infancy on learning DDD so excuse the question if it doesn't make sense..

The background: My team went through an event storming and also a "Boris-esque" exercise to create some contexts, events, external services etc. Let's say we have an Underwriting, Claims and Inspections context. There is a policy issued event that Underwriting fires to create a policy in the Inspections context, and another event from there to Claims. (simple example).

How do these concepts then become features/epics? Do you write features based off the context? are they smaller than that? Do events need their own Epic?

Example epics we created were "Produce Policy" and then "Consume Policy Event" (for Inspections). Let's say there is a service that needs to be called, so we have a "Call Credentialing for Policy" epic.. But to me this doesn't seem right.

  • 1
    Does this answer your question? How is architectural design done in an agile environment?
    – gnat
    May 12 at 14:18
  • Thanks for the question, but that does not answer my question. I will edit my question to make it more clear!
    – Austin L
    May 12 at 14:26
  • 1
    You know, in the end it doesn't matter; you and your team can get together and decide on what the mapping to your software tools should be. Make it up. Have another brainstorming session about it until everyone is on the same page. If you've delved deep into your DDD analisys, you probably have a fairly good idea of what you need to build - chop it up into tasks organized in some way that makes sense for you. Ultimately, there's no such thing "agile features and stories" - stories are just one of the approaches that are out there. Adhering to a rigid form is the opposite of Agile (and DDD). May 16 at 17:37


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.