Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Application Service Methods per Class #17

Open
boedy opened this issue Sep 22, 2016 · 0 comments
Open

Multiple Application Service Methods per Class #17

boedy opened this issue Sep 22, 2016 · 0 comments

Comments

@boedy
Copy link

boedy commented Sep 22, 2016

Hi, Thanks for your awesome book! I have a question:

On page 306 your say:

Using a dedicated class per Application Service makes the code more robust against external changes (Single Responsibility Principle). There are fewer reasons to change the class, as the Service does one and only one thing. The Application Service will be easier to test, seeing as it does less things. It’s easier to implement a common Application Service contract, making class decoration easier (check out the chapter on transactions in Repositories). This will also result in higher cohesion, as all dependencies are exclusively dedicated to a single use case.
The execution method could have a more expressive name, like signUp. However, the execute Command pattern186 format standardizes a common contract across Application Services, thereby enabling easy decoration, which comes in handy for transactions.

How would you handle viewing " one wish" vs e.g. "All whishes"? Would this be:

  1. Two separate classes for the two use cases
  2. One class; Two methods
  3. One class; logic handled in the execute method based on parameter / request obj
  4. Another option?

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant