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

Project suggestion for example #7

Open
yvoyer opened this issue Apr 26, 2016 · 3 comments · May be fixed by #8
Open

Project suggestion for example #7

yvoyer opened this issue Apr 26, 2016 · 3 comments · May be fixed by #8

Comments

@yvoyer
Copy link
Collaborator

yvoyer commented Apr 26, 2016

Here is what I thought could represent a good use case to start an example of ddd with all types of relations (one to many, many to many), while being not too complex.

I will make a draft with tests to start a domain model (without symfony, doctrine or command bus). From there, we'll be able to start doing infrastructure, and application context.

Domain requirements:

Mr. Smith is the proud owner of the restaurant Smith's Pizzeria. He wish to have a site to manage it's company and promote it's products on the Web. Here are the requirement he wishes you to implement.

  • The owner is the only employee granted to create new or delete recipes.
  • Recipes have ingredients that can be categorized with allergens
  • a cashier takes the orders of phone, drive through or take out customers
  • a delivery boy (or girl) delivers prepared meals to the customers who ordered by phone
  • a waitress takes orders to seated clients
  • waitress serve the meals to in house customers.
  • performance bonus are alloted to each trimester based on waiting time of customers. Lower it is greater the bonus.
  • bonus are calculated according to the following chart, based on type of client and average time to serve clients (todo)
  • recipes are not available to customers as long as they have not been released.
  • recipes can be back ordered which means that no customers can order them.
  • retired recipes no longer appears on the menu, they have been removed from production.
  • front desk, drive through and in house customers do not keep order history, they are considered anonymous customer, while Web and phone customers are identified with their phone number to track their orders.
  • delivery boy pickup the customer order at an hour, and are expected to deliver it in order of priority based on ordered at time.
  • Waitress should serve all meals of the customer table at the same time, but for bonus reason, the clock start ticking when the first table customer order is entered to the last meal served
  • cashier make the customer pay on order, while delivery boy make them pay when order delivered, and waitress make them pay at end of diner.

@webdevilopers Any other cases you would need that could represent the domain?

@webdevilopers
Copy link
Owner

webdevilopers commented Apr 26, 2016

Sounds great @yvoyer ! I like the use cases because they will also show the responsibilities of Aggregate Roots on shared Objects.

If we don't want to make it a Symfony App yet I would suggest to always keep a clean Domain master branch.
Later I will add Symfony in new branch. Maybe we will never merge these branches in the end.
They just share the src/Domain/... namespace.

Regarding Symfony I think I will be able to provide:

I'm not sure yet where to put the Commands, Queries and Handlers. Currently they live in my Application folder. Because they are not Services directly related to the Domain Model.
Those kind of services would belong into the Domain folder.

Have you read the DDD in PHP book yet?
https://leanpub.com/ddd-in-php

Because it suggests an interesting structure for the Domain. E.g. using DomainModel instead od Domain\Model.

@yvoyer
Copy link
Collaborator Author

yvoyer commented Apr 26, 2016

Have you read the DDD in PHP book yet?
https://leanpub.com/ddd-in-php

Yes and it's definitely a good resource on the subject.

I'll do the domain object pr, and we should be able to develop more on the structure before merging it in master.

About the symfony app, I would put it in the infrastructure context.

The bus and command could also be in infrastructure and do the mapping between the app and domain.

@webdevilopers
Copy link
Owner

Are you sure about the Infrastructure? In DDD in PHP chapter 11.1 it says:

As Vaughn Vernon says, “Application Services are the direct clients of the domain model”. You could think about an Application Service as a point of contact between the outside world (html forms, API clients, command line, frameworks, UI, etc.) and the Domain Model itself.

There is also an example of an DTO with this namespace:
namespace Lw\Application\Service\User;

It continues in chapter 11.3 Anatomy of an Application Service.

@willdurand also commented on this:

Forms + Validation are part of the Presentation Layer. The Application Layer leverages this layer to get data, then creates a DTO (Application Layer), and calls a Factory (Application Service) to create an Entity (aggregate) using the DTO.

http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/#comment-994246916

But it was an alternative to the Command Bus - to the examples by @mathiasverraes:
http://verraes.net/2013/04/decoupling-symfony2-forms-from-entities/

I agree with @beberlei:

Commands and Handlers are part of the Service-Layer, wrapped by some dispatcher (the CommandBus in the blog post you mentioned). Handlers are sort of the Services.

I think he relates to the Application Layer Services, not the Domain(Model) Layer.

A the bottom line I don't think a Symfony Bundle fits into Infrastructure, Application or UserInterface / Presentation. The functionality should be separated.

Infrastructure:

  • Persistence
  • Logging

UserInterface / Presentation:

  • Controllers
  • Views
  • Forms

Application:

  • Command, Queries and Handlers

Domain(Model):

  • Domain Models (becoming ORM Entities using XML Mapping from the Infrastructure Layer).

We need more feedback on this! ;)

@yvoyer yvoyer linked a pull request Apr 28, 2016 that will close this issue
10 tasks
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

Successfully merging a pull request may close this issue.

2 participants