September 25, 2014
- HTTP Request -> Received by Controller
- Controller -> Serializes request data into command
- Controller -> Passes Command off to Command Bus
- CommandBus -> Resolves Command to Handler
- Command Handler -> Receives Request, create or retrieve/update or delete Entities, persist changes to data layer via Repositories
- Entities -> aggregate events on domain logic around them
- Repositories -> Transport Entities to and from the database, return any entities that have been requested
- AR Model -> save
- Command Handler -> Dispatch aggregated events on entities
- Command Handler -> return Entities in a Response
- Controller -> receives command response and process it, sets view data, handles redirects, set headers, etc
- Response -> built by the controller and now dispatched
Commands / Handler Layer -> The point of this is to abstract the business logic out of the controller. Each controller action has its own set of unique dependencies and by extract them to commands they are isoloted and perform only the actions necessary for that command. ViewPostListing, CreateNewPost, etc.
Service Layer -> The point of this layer is to handle interacting with the different repositories. An order for example is complex and has customers, order items, etc. We cant put this logic in a single repository so it has to exist another layer up as the repositories are responsible for interacting further down the stack. It also provides a layer to implement caching on find() operations. If this layer becomes too complex it may need to be broken out into EntityReaderService, EntityCreatorService, etc.
Repository Layer -> The point of this layer is to abstract away from interacting with the model directly. This way the backend can be completely changed and we would only need to create a new Repository that implements the same interface that interacts with the new ORM, data mapper, nosql, etc.