Keeping in touch with the domain experts is crucial in DDD in order to gain domain insight and as Scott Millett and Nick Tune says in their book called Patterns, Principles, and Practises of Domain Driven Design, DDD refers domain experts as people who deeply understand the business domain from its policies and work flows, to its nuisances and idiosyncrasies. They can be anyone who has a great grasp and understanding for the domain you are working in regardless of title. And also its recommended that to enable a high level of collaboration, you (being a developer) collocate the development team with domain experts who will be on hand to answer questions and participate during analysis at impromptu corridor or break room meetings.
Below there will find some questions which you can ask to domain experts that can make you understand easier the ultimate goal. The questions were taken from the blog page of Greg Young
-Where does the need of this system come from?
-How will this system give value to the business?
-What would happen if this system wasn't built?
-What is the smallest possible thing we can do to deliver this business value?
-What is the need this system fills, not “what it does”
-If I turned off the server tomorrow who would be the first person to notice and why?
-How would you verify that this is working correctly?
-What is the earliest point you can know whether the system has any value to you? How will we do this?
-Why are we starting here?
-What is the minimal setup needed for first release?
-If we could keep only half of the existing features, what would they be?
-How much money do we gain or save from this change?
-What is the smallest step that would give us the most benefit?
-What is the least beneficial technology in our stack?
-How expensive would it be NOT to solve this problem?
-What if we take 1 developer away from this project?
-What would happen if our entire datacenter crashed and all data is lost?
-What is the time frame?
-When this must be in sandbox/ready for testing/production?
-Lay out few different directions to implement this (in terms of SW architecture)?
-How they differ?
-How much will cost us to switch from variant A to B?
-Who will be engaged in this task/project?
-Who will give feedback/requirements?
-Who will tell that it is completed.
-Under what exact circumstances / business operations could this issue occur?
-What are the chances of this happening? Or, how big is the window of opportunity for this to occur?
-What is the business impact of something like this happening?
-Is it possible to mitigate the chances of it happening through design of the business operations?
-Can it be automatically detected?
-How quickly can it be detected after the issue occurs?
-Can it be compensated (fixed) after occurring?
-Can the compensation be automated and transparent?
-What part of the business solution is not solved (or is the domain expert unsure in any area)?
-What in your processes changes most? Why?
-What part of the system took you the longest to learn/understand? Why?
-How’s this any different from … ?
-Are we really in the business of … ?
-Is it going to be worth anything beyond the first use ?
-How hard would it be for a competitor to come up with the same thing ?
-How likely are users to understand this feature ?
-Do you know what end users want, what they care about? Can we give it to them?
-How much can be removed from the product? Does it get better or worse?
-Do you know where bottlenecks occur in the system?
Hiç yorum yok:
Yorum Gönder