search

dddshelf / ddd-in-php-book-issues

Leave your comments, improvements or book mistakes as an issue! Thanks ❤️
https://leanpub.com/ddd-in-php
28 stars 2 forks source link

Suggestion: Explain code organisation for workflows (business processes) #72

Closed VolCh closed 7 years ago

VolCh commented 7 years ago

For example, we get next simple workflow (business process) from domain experts:

  1. When user signed up with email and password then: 1.1. Created entity in UserRepository with status 'new' 1.2. Sended the email with unique confirmation link (for simple example with id and hash from id & email) and changed status to 'pending' on success sending
  2. When user confirmed his email then: 2.1. The User status changed to 'confirmed' 2.2. "Hello email" sended to the user 2.3. The manager notified by some method (for example by email too) about confirmed user

I'm not sure about best code organisation even for this simple workflow with 1:1 relation between the workflow state and one (and only one) domain entity (User with status property). What should be scripts 1. and 2.. Are they application services? Not sure. Are they infrastructure service? Not sure. They look like concrete domain services with domain entity (User) and infrastructure service (EmailNotifierService implements domain NotifierService interface for example) dependencies. Where are these services instances should created in this case? In application service with UserRepository & NotifierService dependency? In application (controller/DI container) like Application & Infrastructure Service? Domain abstraction leaks. Or they should be abstract classes (not interfaces! they realize pure business logic!) with Infrastructure implementations?

keyvanakbary commented 7 years ago

This is not really an issue on the book I guess but I'll try to answer anyway :)

Application Services are the gatekeepers of the Domain. They translate the outside & foreign world to something the Domain understands, translating primitives to Domain Concepts and coordinating Domain Services. I guess 1) and 2) (and subsections) should be Domain Services as they operate business logic. Probably you could have SignUpService and ConfirmAccountService with the proper concepts collaborating with them like Notifiers and Repositories. The implementation of those (SQL, Email, etc.) belongs to the Infrastructure layer.

I hope it helps, closing the issue now 👍 :)