Laravel × Clean Architecture

Agenda
1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
- What steps were taken to introduce it?
- What kind of structure was used for the implementation?
- Good points and bad points

Transcript

1. 　　 Takayuki Suzuki Laravel × Clean Architecture
2. Agenda 1. What is DDD x Clean Architecture? 2. What kind of systems is it suitable for? 3. How was the actual implementation in Laravel? - What steps were taken to introduce it? - What kind of structure was used for the implementation? - Good points and bad points
3. My Presentation the Target Audience 0 • People who want to challenge themselves with DDD • People who want to learn about use cases of DDD x Clean Architecture in Japan
4. Question for everyone 🙋 0 Has anyone ever used DDD or Clean Architecture in their work?
5. Self-Introduction 0 - I’m Takayuki Suzuki. - I worked Full Speed Inc. as a web engineer. At Full Speed, was responsible for developing the management interface for a large-scale advertising distribution service, engaging in a wide range of development from server-side to front-end. - I worked as a freelance engineer for about one year. - Founded Re:Build Inc. in Okinawa in November 2017. - Last year, my company joined the Relic corporate group in Tokyo. Hobbies: full marathons, watching baseball, watching soccer, cosplay, reading manga.
6. 0 Conclusion of my presentation • I actually tried introducing DDD and Clean Architecture in a system development project. However, it took a lot of man-hours. • Then, if you are going to use these, I think it is best to focus only on the main contexts in large-scale system development projects and implement them. • Also, I believe that DDD and Clean Architecture are suitable for systems that need to be operated over a long period of time.
7. 1. What is DDD x Clean Architecture?
8. 1 What is Domain-Driven Design (DDD) ? Domain-Driven Design (DDD) is a software development methodology that emphasizes understanding and representing the problem domain to be solved, placing that knowledge at the center of software design. https://qiita.com/tarokamikaze/items/d368e31edefc6a705625 Advantages Disadvantages ・The introduction of a ubiquitous language allows developers and business stakeholders to converse using the same terminology. ・It achieves an architecture that is resilient to changes. ・It has high long-term maintainability. ・High initial learning costs. ・Increased design and development effort. ・Risk of over-engineering. Problem Domain Core Domain Subdomain Generic Subdomai n Support Subdomai n Solution Domain Bounded Context
9. 1 What is Clean Architecture? Clean Architecture divides the concerns of an application into four layers, clarifying the responsibilities of each while ensuring that inner layers do not depend on outer layers. ・Structure that is resilient to changes ・Improved testability ・Enhanced maintainability and readability ・Easily transitioning to another PHP framework by consolidating business logic in Pure PHP ・High initial learning cost ・Increased number of files and complexity ・Development speed may slow down Advantages Disadvantages
10. 1 Clean Architecture Overall diagram The class structure diagram is shown below. Also, the diagram categorized by each layer is on the right. After this, I will also explain how this diagram was implemented in Laravel. https://zenn.dev/sre_holdings/articles/a57f088e9ca07d
11. 1 Comparison with each architecture The differences between the architectures using DDD are as follows. After, I will explain why Clean Architecture was chosen shortly. Item Clean Architecture Hexagonal Architecture Onion Architecture Metaphor of Structure Concentric Circle (Layer) Structure Hexagon (Port-Adapter) Structure Onion (Layer) Structure Method of Connection with External Separated at Interface Adapter Layer Explicitly Separated by Port (I/F) and Adapter Connects with Infrastructure at Outer Layer Direction of Dependency One Direction (Inward) One Direction (Inward) One Direction (Inward) Characteristic Terms Entity, Use Case, Adapter Port-Adapter Domain, Service, Infrastructure Relation with Framework Most Loosely Coupled (Complete Independence Recommended) Loosely Coupled (UI/DB are all external) May be Applied Somewhat Loosely Handling of Infrastructure Layer Completely Separated at Outer Layer Connected as Adapter Separated by Positioning at Outer Circle
12. 1 Reference Books When Japanese engineers study Clean Architecture, they usually read books by Robert C. Martin. this books are popular.
13. 2. What kind of system is it suitable for?
14. 2 What kind of systems is it suitable for? The systems that are suitable and unsuitable for DDD are mainly as follows. Unsuitable systems Financial systems Inventory and logistics management systems Insurance and medical systems Organizational management systems CRUD-centered easy systems Temporary PoC or MVP Systems primarily integrated with external SaaS Suitable systems
15. 2 Systems Suitable for DDD The reasons why DDD is suitable for certain systems are as follows. Classification System Examples Reasons Financial Systems Banking account systems / Securities trading platforms There are many complex transaction rules, regulations, and state transitions. High frequency of changes necessitates meticulous logic management. Inventory and Logistics Management EC inventory management / Supply chain management Optimization of multiple state management, transactions, and business flows is required. Insurance and Medical Insurance contract management / Claims management There are many detailed business rules based on laws, leading to concentrated logic within the domain. Organizational Management Attendance, payroll, and evaluation systems / HR SaaS These cover a wide range of business knowledge, including Japan's unique organizational structure, rules, and personnel evaluation. Strong business uniqueness in the product Web services with unique matching logic Differentiating factors depend on business logic, making domain model design a competitive advantage. Subscription and Billing Management SaaS billing management / Subscription automation systems There are complex plan designs, discounts, and campaign processing involved. Domain knowledge is closely tied to the logic.
16. 2 Systems Unsuitable for DDD The reasons why DDD is unsuitable for certain systems are as follows. Classification Examples of systems Reasons CRUD-centric easy systems Simple DB CRUD such as customer management, product management There is little business logic, making the cost of DDD unjustifiable. PoC or MVP Beta version web apps, demo versions Emphasis on speed over design; prone to over-design. External SaaS integration centric API integration hubs like Zapier The main purpose is integration and flow control rather than domain focus.
17. 2 Japanese companies that have actually implemented DDD Company Name Company Scale System Overview Used Languages/Frame works DDD Implementati on Clean Architecture Implementation NoSchool (Manalink) Small (Startup) Online tutoring matching and lesson platform PHP (Laravel), Vue.js ◯ (DDD-oriented ) ◯ Monotaro Large (Public Company) BtoB e-commerce site, inventory and order management, etc. Java, Spring Framework △ (Partially implemented) ◯ LINE Yahoo Large (Public Company) Common infrastructure and various API groups for large-scale services Java, Kotlin, Go, etc. ◯ △ Persol Career Co., Ltd. Large (Public Company) Reconstruction of job matching service (doda direct) Java, Spring Boot ◯ ◯ Askul Corporation (LOHACO) Large (Public Company) Renewal of e-commerce site LOHACO Java, Spring Framework ◯ ◯ Caddy Inc. Medium (Startup) Order management platform for manufacturing industry Go, TypeScript (NestJS) ◯ △ (Partially implemented) Navitime Japan Medium (IT Company) New development of travel app Kotlin, Spring Boot ◯ △ (Partially implemented) Mercari Large (Public Company) Marketplace infrastructure with microservices Go ◯ ◯ LayerX Medium (Startup) Blockchain-related products TypeScript ◯ ◯
18. 3. How was it actually implemented with Laravel?
19. • Structure resistant to change • Improvement of testability • Improvement of maintainability and readability 3 Why did we choose Clean Architecture? • Complex domain knowledge is needed for payment-related features • It is determined to be operated for a long term over a period of ten years • There is a lot of business logic • There is a reasonable development budget • There is a possibility of switching to another PHP framework in ten years Features of Clean Architecture Features and issues of our system
20. 3 What steps did we take to implement it? Design phase Development phase event storming context map Use case diagram ubiquitous language domain model diagram domain model domain model bounded context domain model domain model bounded context domain model domain model bounded context
21. 3 A list of documents we have created • Event Storming Diagram • Context Map • Use Case Diagram • Use Case Description • Domain Model Diagram • Sequence Diagram • API Specification Document Creating an Event Storming Diagram may be unusual.
22. 3 What is an Event Storming Diagram? Event Storming is a collaborative modeling technique used to share, visualize, and understand complex business processes and domain knowledge.
23. 3 Example of a diagram I made personally
24. 3 Context and domain examples Order/purchase core domain order context Payment (support subdomain) Delivery (support subdomain) Billing/Billing (support subdomain) Purchase (supported subdomain) Notification (generic subdomain) Membership registration (general purpose subdomain) Support subdomain Generic subdomain
25. 3 What class structure did we develop? Adapter Layer Infrastructure Layer Use Case Layer Domain Layer Controller Repository Eloquent Model Logger Interactor IUsecase ILogger OutputData Entity IRepository Service InputData Class Call implements ValueObject Request Response
26. 3 What class structure did we develop? Adapter Layer Infrastructure Layer Use Case Layer Domain Layer Controller Repository Eloquent Model Logger Interactor IUsecase ILogger OutputData Entity IRepository Service InputData Class Call implements ValueObject Request Response These allow you to write your business logic in pure PHP and easily migrate it to other PHP frameworks.
27. 3 Directory structure • explanation ◦ Create a domain directory under the context. ◦ Next, create the Adapter, Domain, Infrastructure, and UseCase directories under the domain directory. ◦ Finally, create a file for each layer. InfraStructure Adapter UseCase Domain
28. 3 Code example Here is an example of the code I created. github link: https://github.com/bumptakayuki/laravel-ddd-clean
29. 3 Looking back at our project • Good Points ◦ We were able to separate Laravel's functions into the infrastructure layer, so if we need to switch to another PHP framework, there won't be any issues. ◦ Since the layers are finely divided, it is easier to identify errors. ◦ I think introducing DDD in a system with a complex domain is good as it helps organize the specifications. • Bad Points ◦ Development took a lot of time. I felt it would be tough unless it was a project with a very generous development budget. ◦ The members developing also need to have knowledge of DDD and Clean Architecture, so the speed during the early stages of development was hard to achieve.
30. Conclusion of my presentation • I actually tried introducing DDD and Clean Architecture in a system development project. However, it took a lot of man-hours. • Then, if you are going to use these, I think it is best to focus only on the main contexts in large-scale system development projects and implement them. • Also, I believe that DDD and Clean Architecture are suitable for systems that need to be operated over a long period of time.