Show Menu
Cheatography

Onion Architecture + Symfony Cheat Sheet by

How to apply the Onion architecture with Symfony framework

Onion Archit­ecture

Layer: Applic­ation Core (appli­cation + domain)
Layer: Presen­tation
Layer: Infras­tru­cture
Layer: Tests

1. Applic­ation Core

Domain
has no intera­ction direct with outerl­ayer. It represents the domain business and domain logic. It defines always the domain specific entities, value objects, events, except­ions, services, factories, interf­aces.
Applic­ation
Applic­ation layer manages the internal domain logic. It provides different applic­ation services, which enable the commun­ication with presen­tation, tests and infras­tru­cture.

1.1 Domain Layer

models
consist of entities, value objects, aggregates
repository interface
interfaces to access the business models, which are used by applic­ation and implem­ented by outer layer. For example: infras­tru­cture
assertions
the business rules to adjust changes on business behavior and business models
services
domain services define the complex internal commun­ication among the domain models. For example: apply some changes cross different domain models.
events
which can be used to track the state changes of domain

1.2 Applic­ation Layer

events / Event Subcriber
defines the events, which represent the state changes in business domain. for example:
services
theser services enable the intera­ction with internal domains by using the predefined interfaces in the domain layer.
query interface
These interfaces are defined for fetching the domain data. They are commonly used by presen­tation layer and implem­ented by infras­tru­cture layer.
command
they are simple objects, which are used to change the state of business domain. For example: confir­mPa­yment
 

2. Presen­tation Layer

contro­llers
contro­llers are the typical gateways for intera­ction comming from end user. It can be a contro­ller, that represents REST endpoint; or a contro­ller, that renders the web page.
consoles
It enables the user to access and update the applic­ation core via console in terminal.
templates
provide the template to define how to represent the business data. for example: template of email, template of exports, template of preview
views/­forms
provide the UX interface to end users
DTO
Data Transfer Object, defines the view model of request and response
Presen­tation layer provides the interfaces how end user can drive the business logic

3. Infras­tru­cture layer

doctrine
query implem­ent­ations
mail
repository implem­ent­ations
filesystem
exports
Queue
cron-jobs
SSO
logging
The infras­tru­cture layer holds the most low level code. Anything in here should be easy to replace. Code here should never effect anything related to logic, or how your applic­ation behaves.

4. Tests Layer

unit tests
test if internal applic­ation core works well
integr­ation
test if the commun­ication between applic­ation core and external services in infras­tru­cture layer is possible
functional
test if the intera­ction between end user and the presen­tation layer work well
Tests layer test the functi­onality of applic­ation core and integation between applic­ation core and outer layer.

Remark 01:

 
Applic­ation core is the indepe­ndent core, which defines the most of core logic and a couple of interf­aces, that must be implem­ented and used by outer layer. The inner applic­ation core should be indenp­endent from outlayer, and should be always runable, if you change any part of the outer layer.

Key tenets of Onion

The big advantag of Onon Archit­ecture is that business logic ends up coupled to ONLY applicaton layer concerns, not to infras­tru­cture layer anymore. The applic­ation is built around an indepe­ndent object model. Inner layers define interf­aces. Outer layers implement interfaces
Direction of coupling is toward the center. All applic­ation core code can be compiled and run separate from infras­tru­cture
 

Symfony Project structure: Core

Core
├── Application
│   ├── Command
│   ├── Event
│   ├── Query
│   └── Service
└── Domain
    ├── Event
    ├── Model
    ├── Repository(interfaces only)
    ├── Service
    └── Validation

Symfony Project structure: Presen­tation

Presentation
├── Api
│   └── Rest
│       ├── Controller
│       └── DTO
│   └── SOAP
│       ├── Controller
│       └── DTO
├── Console
│   └── Command
│   └── DTO
└── Web
    ├── Backoffice
    │   ├── Asset
    │   ├── Controller
    │   ├── DTO
    │   ├── Form
    │   └── Twig
    └── Portal
        ├── Asset
        ├── Controller
        ├── DTO
        ├── Form
        └── Twig

Symfony Project structure: Infras­tru­cture

Infrastructure
├── Mail
├── Persistence
│   └── Doctrine
│       ├── Migrations
│       └── Repository
├── Queue
└── SSO

Symfony Project structure: Tests

Tests
├── functional
├── integration
└── unit

Remark 02

 
Applic­ation layer should never use the concret implem­ent­ation from infras­tru­cture layer or presen­tation layer. It defines the applic­ation interfaces and manages the domainer interf­aces, so that the applic­ation core can work a wohle without outerl­ayer. By providing the different applic­ation services, the commun­ication with tests, presen­tation and infras­tru­cture is possible.
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          System Design Cheat Sheet
          Selenium WebDriver Cheat Sheet Cheat Sheet
          ISTQB Test Automation Engineering Cheat Sheet

          More Cheat Sheets by vikbert

          Clean Code Cheat Sheet