Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Just for discussion, to me it seems that 2 different terminologies actually are saying the same thing. Is there any tangible differences between this 2 design approaches?
Use Cases focus on Users, Actions, and Processes. This is great from a business perspective, because everyone can see an abstracted view of what the system will provide.
DDD focuses on creating software that solves problems. The ‘Who can solve this?‘ and the ‘What process will they follow?‘ come afterwards.
DDD really gets to the core problems earlier in the design process, and helps you structure your solution (i.e. identifying Entities, Value Objects, Respositories, Domain/Application/Infrastructure services, Bounded Contexts, Specifications, etc).
Use Cases don’t cater for this at all, or how to manage your development (Anti-Corruption Layers, Separate Ways, etc)
In my experience, DDD offers more flexibility (changing requirements anyone?), and provides the foundations for your Use Cases. Once you’ve got your Domain Model in place, Use Cases can be implemented using Controllers/Workflow Engines/UIs that connect with your Domain Model. Quite often, I’ve identified gaps in business requirements just by building Domain Models.
And having attended a talk by Ivar Jacobsen some years ago, I would also say that DDD is better suited to Agile.