Design Methodology: use case driven vs. domain driven

Question

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?

Answer 1

To me, Domain-Driven Design (DDD) is more "all emcompassing"; where as Use Cases are just a tool that focus on a specific view: how a something responds to stimulus and are used to capture or document behavioral requirements.

To me, the term "domain" is a loaded one - it infers a wider view of all the concepts relevant to a specific problem area.

When describing how parts of the domain interact - specifically how they respond to stimulus then you might use Use Cases.

As far as an approach goes: Use Cases are the "additional" view in the 4+1 Architectural View Model, but they aren't a design approach on their own.

Another distinction is that DDD is often very closely tied to an Object Orientated model or system; in this way DDD captures / respresents (amongst other things) the structure of a system - some thing Use Cases don't do.

Answer 2

This is my personal interpretation based on experience.

Use case driven design uses use case as a tool to discover the entity, interface, interaction message and the workflow on how certain business operation is being conducted. This is used often in more analysis or design stage to gather or understand the requirements and establish some initial designs. DDD on the other hand is more oriented toward implementation with strong focus on the domain entity and context. It focuses in more details than the use case in term of defining the model (such as classes, interfaces) and defining its boundary, aggregations, operations and domain specific logic. It generally follows some standard practice on how to approach them in implementation.

DDD is more suitable when you are dealing with project that target a specific domain such as accounting, engineering, where you can foresee that some or most of the models in the business can have complex interrelation and embodied logic. Choosing between use case driven design or DDD also depends on the availability of the domain experts. If you have stakeholders with business needs (only some access to the domain experts), then use case driven design is more suitable if compared to DDD.It is high risk to adopt DDD if you do not have domain experts participating directly in the development of the project.

Personally I think they can both complementing each other in some projects where you can start with use case driven design and approach the detail design and implementation using DDD approach

Answer 3

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.

Answer 4

Domain-driven design essentially tries to act as if you knew all the possible use-cases in advance. By definition, the "problem" domain is the set of specific problems that are considered members of that domain.

Answer 5

Use case driven approach works fine if you have only one client for product and client has already told you about all problems that needs to be solved by product. This is possible in service oriented companies in general. It becomes difficult to manage when you have multiple clients for same Product. This happens generally in Product developing companies. In such cases (Product Driven Companies ) DDD comes to handy. You develop a product using DDD (you call it as base).Then check, are all use cases for new client are applicable, if not then form a layer over base for client specific changes.

Answer 6

I'm not expert on this, and these terms can be fuzzy, and mean different things to different people. But..

I would have said that a Domain Design was where there was an existing system (paper based, manual, whatever) and the software models the actual entities in the system. So in a Library system you look at a library, and see that there are books, and shelves, and cupboards, and rooms. And based on that you model the real domain in the software.

With Use case you start with 'what are we trying to do' It may be that you don't need different rooms in your model, because they are not needed in the use cases. That makes your system simpler (and less error prone) but if you are not modelling the 'real world' then you lose some flexibility.