The Clean Architecture in PHP

Transcript

1. The Clean Architecture
2. WE GOTS PROBLEMS
3. WE LIVE OR DIE BY THE FRAMEWORK
4. SO MANY COOL LIBRARIES
5. WE CAN'T TEST ANYTHING
6. CHANGE BREAKS EVERYTHING
7. HOW DO WE FIX THESE PROBLEMS?
8. THE CLEAN ARCHITECTURE Coined by Mr. Uncle Bob
9. THE ONION ARCHITECTURE Coined by Jeffrey Palermo
10. SOFTWARE IS COMPOSED OF LAYERS
11. MVC is a start of those layers: Model View Controller
12. MVC Kinda Sucks Rails pushed the "fat model, skinny controller" mantra
13. MVC Kinda Sucks With only 3 layers, this becomes the "obese model, skinny controller"
14. The Solution? More layers, obviously...
15. DOMAIN MODEL
16. Domain Model is Our Entities
17. Domain Model is Plain Old PHP Objects
18. Domain Model has No dependencies except for PHP
19. Domain Model is Transferable We should be able to drop the Domain Model into any PHP project and have it work as intended.
20. DOMAIN SERVICES
21. Domain Services is dependent upon the Domain Model and nothing else.
22. Domain Services is Plain Old PHP Objects
23. Domain Services use the Domain Model layer to do things.
24. Domain Services together, with Domain Services, create the Business Logic Layer.
25. Business Logic the rules that define what the application does and does not
26. Business Logic is relationships, processes, and data workflow
27. Business Logic is not processing forms, routing requests or creating csv files
28. Business Logic is the stuff that stays the same regardless of language, framework or interface
29. Application Services are services provided by your framework.
30. Application Services is session management, pagination, and authentication
31. Application Services utilize your Business Logic Layer in the context of your application (web based vs desktop)
32. Application Services depends upon the Domain Model and Domain Services to function
33. User Interface is stuff the user sees
34. User Interface is the HTML, JavaScript, CSS, Images, etc that make up the user experience
35. User Interface is also the controller that serves the request.
36. User Interface M VC Data UI
37. Infrastructure are the mechanisms that give your Domain Model meaning
38. Infrastructure is responsible for hydrating and persisting the Data Model
39. Infrastructure connects with external resources to hydrate and persist the data
40. Infrastructure vs UI are different layers, but on the same level of the Onion
41. Infrastructure vs UI UI (Controllers) CANNOT talk to infrastructure
42. Infrastructure vs UI Controllers utilizing Infrastructure directly is like supergluing ourselves to an implementation
43. External Data Sources old school thought: Databases are central to an application. Apps revolve around the DB.
44. External Data Sources old school thought: Databases are central to an application. Apps revolve around the DB.
45. External Data Sources Databases simply provide a means of hydrating your Domain Model
46. External Data Sources Your Domain Model is central to your application. It is the core of the Onion.
47. External Data Sources Our application does not depend on the database.
48. External Data Sources Our application depends on data.
49. External Data Sources Where does that data come from? We don't care!
50. External Data Sources API Files Relational Databases NoSQL Variants
51. External Data Sources Whatever.
52. So how does this work?
53. Dependency moves inward
54. Inversion of Control Inversion of control is taking the control of dependencies away from the object, and giving it to some third party who provides an object with its dependencies.
55. Inversion of Control Some things can't know about other things, but we can use interfaces to inject other things into some things. LOL.
56. Dependency Injection Simply inject a dependency into an object that needs it, either view construction or using set methods.
57. Dependency Injection Previously... class CustomerController extends AbstractController { public function indexAction() { $repository = new CustomerRepository(new EntityManager()); $customers = $repository->getAll(); return ['customers' => $customers]; } } Controllers shouldn't know what repositories are...
58. Dependency Injection Instead... class CustomerController extends AbstractController { protected $customersRepository; public function __construct(CustomerRepositoryInterface $repo) { $this->customerRepository = $repo; } public function indexAction() { $customers = $repository->getAll(); return ['customers' => $customers]; } }
59. Dependency Injection A class simply asks for some object conforming to the dependent interface. We don't care what we get, as long as it does what we want.
60. Domain Model = Entities class Customer extends AbstractEntity { protected $name; protected $channel; public function setName($name) { $this->name = $name; return $this; } public function getName() { return $this->name; } }
61. Domain Services ▪ Repositories ▪ Factories ▪ Services
62. Repositories ▪ Retrieve things from data sources ▪ Store things in data sources
63. Repositories But Domain Services are too deep in the Onion to know about data sources...
64. Repositories Arm yourself with interfaces!
65. Repositories Domain Services should provide a contract for the Infrastructure Layer to adhere
66. Repositories interface CustomerRepositoryInterface extends RepositoryInterface { /** * @param int $id * @return AbstractEntity */ public function getById($id); /** * @return array */ public function getAll(); }
67. Repositories Use Dependency Injection for components that cannot depend on the Infrastructure Layer directly
68. Factories Factories create things. They know the business rules around construction and adhere to them.
69. Factories As part of the Domain Services layer, they can only depend on other Domain Services and the Domain Model
70. Factories class CustomerFactory { // ... public function create() { $customer = new Customer(); $customer->setType($this->typeRepository->getByCode('R')); $customer->setCreditLimit(0); $customer->setCreditStatus($this->statusRepository->getByCode('P')); return $customer; } }
71. Factories Domain Services are your Business Logic Layer. They know how to create things. Your controller doesn't know, but it does know data, and it does know the factory's phone number.
72. Services Services are classes that do things for you or figure things out for you. They know about your data, and they know about your business rules.
73. Services Services are things like billing runs, usage statistic calculators, permission checks, etc.
74. Services Works with data, but doesn't create (Factory), retrieve or persist data (Repository).
75. Services namespace Uss\Domain\Services\Billing; class Billing { public function generateInvoices(\DateTime $invoiceDate) { $orders = $this->ordersRepository->getActiveBillingOrders($invoiceDate); foreach ($orders as $order) { $invoice = $this->invoiceFactory->create($order); $this->invoiceRepository->persist($invoice); } $this->invoiceRepository->flush(); } }
76. Services namespace Uss\Domain\Services\Billing; class Taxes { public function calculateTaxes(Invoice $invoice) { if ($this->isAccountTaxExempt($invoice->getAccount()) { return; } foreach ($invoice->getOrder()->getComponents() as $component) { $invoice->setTaxes( $this->taxRepository->getBy( [ 'type' => $component->getServiceType(), 'geocode' => $component->getLocation()->getGeocode() ] ); ); } } }
77. UI: Controllers ▪ Accept Data (GET, POST, PUT) ▪ Validate Data ▪ Use the Domain Services Layer to do things ▪ Return a view, or redirect to another controller
78. UI: Controllers Do Not ▪ Contain business rules ▪ Access the database ▪ Do things...
79. UI: Controllers Should ▪ Have a specific purpose ▪ Not have many actions ▪ Have very short actions (methods)
80. UI: Controllers Should SOLID S = Single Responsibility Principle Every class should have one, and only one, responsibility
81. UI: Controllers A PartnerController should only be concerned with managing a Partner (View, Edit, Delete)
82. UI: Controllers If Partners have Contacts, Documents, and Deals, those should all each be their own controllers. Single responsibility.
83. Small Controllers. Why?
84. class CustomersController extends AbstractActionController { public function __construct( AddressRepositoryInterface $addressRepository, AgingHistoryRepositoryInterface $agingHistoryRepository, AliasRepositoryInterface $aliasRepository, SocialRepositoryInterface $socialRepository, ContactRepositoryInterface $contactRepository, CustomerRepositoryInterface $customerRepository, StatusRepositoryInterface $statusRepository, MaintSurvTicketRepositoryInterface $ticketRepository ) { $this->addressRepository = $addressRepository; $this->agingHistoryRepository = $agingHistoryRepository; $this->aliasRepository = $aliasRepository; $this->socialRepository = $socialRepository; $this->contactRepository = $contactRepository; $this->customerRepository = $customerRepository; $this->statusRepository = $statusRepository; $this->ticketRepository = $ticketRepository; } }
85. Have fun testing that.
86. Have fun refactoring that.
87. UI: Controllers Controllers are stupid. They should contain no logic besides retrieving data and knowing which Domain Services to call.
88. UI: Controllers All business logic should go within the Domain Services layer. All processing logic should go in the controller.
89. Dumb Controllers. Why? DRY. If business logic is in the controller, we can't reuse it. Single Responsibility. A controller is only responsible for responding to requests and dispatching views.
90. Why are we doing all of this?
91. FRAMEWORK INDEPENDENCE
92. DATABASE INDEPENDENCE
93. EXTERNAL AGENCY INDEPENDENCE
94. USER INTERFACE INDEPENDENCE
95. TESTABLE