0

on current project, we area trying to implement use-cases as objects, e.g.:

public class SaveSalesOrderUseCase {
    public void Execute(SalesOrderUseCaseModel salesOrderModel) {
       // implementation as list steps defined in use-case
    }
}

Does it make any sense to design system this way? How it could (positively and negatively) affect design of system with regards of OOP, SOLID principles and domain model etc.?

Any experience?

Thank you.

Zdenek Sejcek
  • 1,367
  • 2
  • 9
  • 8

4 Answers4

4

Use cases are not intended to reflect the structure of a system they are meant to reflect it's behavior.

Does it make any sense to design system this way?

Not really, requirements frequently change. This can result in the class no longer reflecting it's intent.

How it could (positively and negatively) affect design of system with regards of OOP, SOLID principles and domain model etc.?

It doesn't really make sense from an OOP perspective.

Use case titles are meant to describe the whole problem benign solved. this will lead to class names that don't reflect a single responsibility.

Which can lead to all kinds of design flaws (especially down the read).

Benjamin Albert
  • 738
  • 1
  • 7
  • 19
  • If you treat system behavior as a first class citizen, the class encapsulating the behavior will have a single responsibility. This is what DCI does very well. – ciscoheat Feb 15 '14 at 19:02
1

This approach may introduce the duplicate code and one use case can span in different domain area where you can find difficulty in maintaining the code. Coming to OOP's , I feel it is a deviation as Use case's are not really Objects. This approach may feel you based on the SOLID principle, but I feel it is not as your use case can span between domains in you case saveOrder may touch Customer domain and Inventory as well with a bit of finance and each has its own SOLID class and you should have Facade class saveOrder to use them.

Kumar
  • 1,106
  • 4
  • 15
  • 33
1

You'd probably do that if you wanted to "industrialize" the execution of use cases, for instance processing queues or batches of them. However, a use case being closely related to a manual action taken by a human user, I can't see much use for that.

Another reason can be if you want to define operations about use cases in general : undo/redo, record execution, etc.

Your use cases would then probably have to inherit a common base class though.

Otherwise, I'd say KISS/YAGNI applies and it is overkill.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
1

I think it is perfectly acceptable to do this. There is an architectural pattern called DCI (Data, context and interaction where an use case is implemented in the context and domain objects play a certain role to fulfill the scenario in that context.

One of the reasons is that the behaviour of the system shouldn't be scattered around in your application. It can make it difficult to understand what is going on.

DCI is not better or worse than other architectures, it is just an option that you can choose.

Jeroen
  • 163
  • 3
  • DCI is surely "better" than traditional OO, since its goal are to alleviate the problems found in that paradigm. – ciscoheat Feb 15 '14 at 18:52