DDD for Domain Experts & Product Owners - Zsofia Herendi - DDD Europe 2020
ฝัง
- เผยแพร่เมื่อ 1 ต.ค. 2020
- Domain-Driven Design Europe 2020
dddeurope.com - / ddd_eu
Have you ever wondered what product people’s role is in DDD? Well, it is a key role because a product person needs to be aware with how the business works, the business strategy and its changes, and need to deliver this information to the team/s clearly in order for them to be able to solve problems that are really important for the business. Because teams are solving real business problems in DDD. But first teams need to learn more about the business to understand their problems and struggles. Who could be a better person than a product owner to share this with the team (derived all these information from the high level business model and strategy)?
What if people don’t want to know more than the bare minimum and they are not curious about the domain and business at all? We, product people need developers and everyone in the team to be willing to know more about the why’s. How do we do this? What is in our toolbox for this? You can learn more on this session and no matter you are a product person or developer you can get useful hints and tips there.
Zsófia is a Product Manager who has spent more than 14 years bringing developers and business people together, 10+ years working on different teams and 6+ years working in an agile environment. She is a skilled modeler with a passion for diagramming and an addiction to optimizing flow. - วิทยาศาสตร์และเทคโนโลยี
Amazing talk. As a dev, when I think of DDD, I think inwards about how I should design. Even when thinking of others, I jump right into just talking about boundaries assuming that the rest of the team has a decent understanding of the domain. But, brainnstorming and learning about a new domain, getting people curious and involved.. these are awesome techniques. Also, seeing the perspective of a "product owner" who is not a domain expert to start with is also something I found new. Thanks for this interesting talk!
DDD is about clarity and reality checks. The goal is to write easily maintainable code. The great help with it is reducing cognitive complexity. That is it.
Product people don’t actually “help” dev team. Usually it’s a dev team who pushes back and make product people to articulate the business in a proper way. It was always like that. And DDD is not about making up requirements during brainstorming sessions. Actually you are wasting devs time if you didn’t do your homework as “product people”
The last talk is hardly about DDD
as much as it is technical, you can't avoid that DDD is about teamwork and the social aspect involved in gathering information.