Skip to content

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

@VolCh

Description

@VolCh

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions