Before you start: make the "business knowledge" person agree to engage in the process. It's going to take days off time to find the aggregate roots.
Also, don't use UML. UML is great if you've got a very complex relational data model and you want to get your OO designed up front; otherwise it's not much use. You're not "being enterprise" by doing UML like this, you need UML up front and part of the system creation.
I tried this method before but I had trouble getting the customer to explain their problems in this way. None of them wanted to engage like this. Instead we got them to write down user stories that described their business processes and then built the aggregate roots, entities and messages from that.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Before you start: make the "business knowledge" person agree to engage in the process. It's going to take days off time to find the aggregate roots.
Also, don't use UML. UML is great if you've got a very complex relational data model and you want to get your OO designed up front; otherwise it's not much use. You're not "being enterprise" by doing UML like this, you need UML up front and part of the system creation.
I tried this method before but I had trouble getting the customer to explain their problems in this way. None of them wanted to engage like this. Instead we got them to write down user stories that described their business processes and then built the aggregate roots, entities and messages from that.