thắc mắc Chia sẽ cách cấu trúc source code dự án lớn laravel

gianghovoz said:
Hiện tại mình làm cho công ty outsource nhỏ thôi . thì thấy dự án laravel chỉ áp dụng design pattern repository giống thế này https://viblo.asia/p/repository-pattern-trong-laravel-gGJ59jPaKX2. không biết nhưng dự án lớn các bác làm thì họ cấu trúc dự án như thế nào .
Click to expand...

Design pattern nào cũng phải thỏa mãn 5 nguyên tắc S.O.L.I.D. Nếu thỏa mãn được thì OK. Còn lại càng đơn giản càng tốt. Keep it simple stupid!
 
Thích Màu Hường said:
Design pattern nào cũng phải thỏa mãn 5 nguyên tắc S.O.L.I.D. Nếu thỏa mãn được thì OK. Còn lại càng đơn giản càng tốt. Keep it simple stupid!
Click to expand...
Như bác này nói, chỉ cần thỏa mãn SOLID thì dự án mặc nhiên sẽ dễ maintain hơn rất nhiều, còn lại thì cứ càng đơn giản càng tốt. Trước mình có đọc về 1 bài viết liên quan đến DDD. Sau này cũng có tham khảo nhiều nguồn thì DDD sẽ giúp cho việc dev mới vào sẽ có thể nhanh chóng hiểu được nghiệp vụ của bài toán. Tuy nhiên nó khi thêm cái DDD vào thì lại mất thêm công định nghĩa folder structure cho từng tầng như Application, Infranstructure v.v.. Bài toán không thực sự lớn thì tốt nhất ko nên bôi thêm vào làm gì.
 
ddd là như thế này à các bác
/app
├── /Application
| ├── /Exceptions
| ├── /Middlewares
| ├── /Providers
| ├── /Requests
├── /Domain
| ├── /MyDomainA
| | ├── /Contracts
| | ├── /Entities
| | ├── /Repositories
| | ├── /Services
| ├── /MyDomainB
| | ├── /Contracts
| | ├── /Entities
| | ├── /Jobs
| | ├── /Listeners
| | ├── /Repositories
| | ├── /Services
| ├── .
| ├── .
| ├── .
├── /Infrastructure
| ├── /Contracts
| | ├── BaseRepository.php
| ├── /Jobs
| | ├── Job.php (Abstract)
| ├── /Listeners
| | ├── Listener.php (Abstract)
| ├── /Repositories
| | ├── EloquentRepository.php (Abstract)
| ├── /Scopes
├── /Interfaces
| ├── /Console
| | ├── Kernel.php
| ├── /Http
| | ├── /Controllers
| | ├── /Providers
| | | ├── RouteServiceProvider.php
| | ├── /Resources
| | ├── Kernel.php
/bootstrap
/config
/database
/docker
/public
/resources
/storage
/tests
/vendor
 
Đúng rồi bạn, nhìn qua thì tưởng chỉ là thêm 1 vài folder nhưng khi chia ra thành từng Domain như này thì sẽ tập chung được nghiệp vụ (Viết trong các contract) sẽ thể hiện như nào/gồm cái gì. Việc chia domain cho chuẩn thì phải làm nhiều có kinh nghiệm về nghiệp vụ chứ mình cũng ko dám chém.
 
Thích Màu Hường said:
Tò mò chút, Repository khác Data Layer (Db) chổ nào vậy thím. Ý thím là database ví dụ như SQL Server, MySQL...?
Click to expand...

Repository là cái pattern abstract mấy cái method crud thôi, để say này dể swap qua mấy db khác(sql/nosql/cloud), nếu dùng thẳng data access thì tight coupled
 
Thích Màu Hường said:
Tò mò chút, Repository khác Data Layer (Db) chổ nào vậy thím. Ý thím là database ví dụ như SQL Server, MySQL...?
Click to expand...
DataLayer chứa các method phục vụ cho run query tới db: đóng mở db connection, run stored procedure, view, query data.
Tầng repo thì có làm côngđoạn mapping từ dataset vào model, xử lý một số caching,..
Việc phân tầng Repo và DataLayer giúp tăng độ Single Reposonsibility thôi, nên trong dự án nhỏ có thể gộp làm 1.
 
gianghovoz said:
ddd là như thế này à các bác
/app
├── /Application
| ├── /Exceptions
| ├── /Middlewares
| ├── /Providers
| ├── /Requests
├── /Domain
| ├── /MyDomainA
| | ├── /Contracts
| | ├── /Entities
| | ├── /Repositories
| | ├── /Services
| ├── /MyDomainB
| | ├── /Contracts
| | ├── /Entities
| | ├── /Jobs
| | ├── /Listeners
| | ├── /Repositories
| | ├── /Services
| ├── .
| ├── .
| ├── .
├── /Infrastructure
| ├── /Contracts
| | ├── BaseRepository.php
| ├── /Jobs
| | ├── Job.php (Abstract)
| ├── /Listeners
| | ├── Listener.php (Abstract)
| ├── /Repositories
| | ├── EloquentRepository.php (Abstract)
| ├── /Scopes
├── /Interfaces
| ├── /Console
| | ├── Kernel.php
| ├── /Http
| | ├── /Controllers
| | ├── /Providers
| | | ├── RouteServiceProvider.php
| | ├── /Resources
| | ├── Kernel.php
/bootstrap
/config
/database
/docker
/public
/resources
/storage
/tests
/vendor
Click to expand...

Eternity95 said:
Đúng rồi bạn, nhìn qua thì tưởng chỉ là thêm 1 vài folder nhưng khi chia ra thành từng Domain như này thì sẽ tập chung được nghiệp vụ (Viết trong các contract) sẽ thể hiện như nào/gồm cái gì. Việc chia domain cho chuẩn thì phải làm nhiều có kinh nghiệm về nghiệp vụ chứ mình cũng ko dám chém.
Click to expand...

Ko rành lắm nên ko dám ý kiến. Nhưng mình có câu hỏi. Chia Entities ở 2 Domain A, B thế này thì nhiều use case nó cần tham chiếu tới entities của nhau ví dụ A có dependency trong B và ngược lại, hoặc thậm chí tham chiếu chéo nhau. Nếu làm đúng thì phải public và giao tiếp qua Interface của nhau chứ ko tham chiếu trực tiếp. Mà như vậy làm tăng sự phức tạp của source code, còn không thì cách đơn giản là gom tất cả enitites của tất cả domain về chung 1 chổ. Ko biết ý kiến của mấy thím về vấn đề này sao? :shame:
 
Thích Màu Hường said:
Ko rành lắm nên ko dám ý kiến. Nhưng mình có câu hỏi. Chia Entities ở 2 Domain A, B thế này thì nhiều use case nó cần tham chiếu tới entities của nhau ví dụ A có dependency trong B và ngược lại, hoặc thậm chí tham chiếu chéo nhau. Nếu làm đúng thì phải public và giao tiếp qua Interface của nhau chứ ko tham chiếu trực tiếp. Mà như vậy làm tăng sự phức tạp của source code, còn không thì cách đơn giản là gom tất cả enitites của tất cả domain về chung 1 chổ. Ko biết ý kiến của mấy thím về vấn đề này sao? :shame:
Click to expand...
Mình cũng đã thực hành thử và cũng như bạn nói đấy, 2 domain có tham chiếu đến entities của nhau và chưa tìm cách dc cách xử lý, nó có 1 khái niệm là Aggregate (tổ hợp nhiều entities). Nhưng mình cũng chưa hiểu đc quá sâu để dám áp dụng vào dự án :((
 
Mỗi domain sẽ full như thế này
app/Domain/Invoices/
├── Actions
├── QueryBuilders
├── Collections
├── DataTransferObjects
├── Events
├── Exceptions
├── Listeners
├── Models
├── Rules
└── States
 
opeo93 said:
2 domain không bao giờ tham chiếu lẫn nhau đâu nhé mấy bạn. Họ thiết kế để k dùng chung đó
Click to expand...

Nhưng về mặt business nó có liên hệ với nhau thì sao? Ví dụ một hệ thống bán hàng, có các domain là Customer Management quản lý thông tin khách hàng, chăm sóc khách hàng và Order Management chuyên quản lý đơn hàng. Như vậy entity Customer cũng phải tham chiếu Order, ngược lại order cũng phải biết về Customer thì thím làm sao? Nếu tách ra làm 2 module riêng biệt thì rõ ràng 2 module này có dependency với nhau.

Mà việc phân tách làm nhiều domain như vậy khi requirement nó thay đổi thì lúc ban đầu 2 domain không liên hệ nhau, cả team code cho đã tới lúc requirement nó đổi, cần lấy thông tin với nhau thì thím làm sao?
 
Thích Màu Hường said:
Nhưng về mặt business nó có liên hệ với nhau thì sao? Ví dụ một hệ thống bán hàng, có các domain là Customer Management quản lý thông tin khách hàng, chăm sóc khách hàng và Order Management chuyên quản lý đơn hàng. Như vậy entity Customer cũng phải tham chiếu Order, ngược lại order cũng phải biết về Customer thì thím làm sao? Nếu tách ra làm 2 module riêng biệt thì rõ ràng 2 module này có dependency với nhau.

Mà việc phân tách làm nhiều domain như vậy khi requirement nó thay đổi thì lúc ban đầu 2 domain không liên hệ nhau, cả team code cho đã tới lúc requirement nó đổi, cần lấy thông tin với nhau thì thím làm sao?
Click to expand...
QueryBuilders đó bạn. với bạn hiểu sai cách dùng DDD rồi.
 
Theo ý kiến của mình, khi dùng một framework bất kỳ. Nếu không có yếu cầu bắt buộc thì nên giữ nguyên cấu trúc của nó, để dễ bảo trì và người tới sau cũng theo kịp được. Khi dự án nở to ra, sửa chữa thay đổi cấu trúc quá nhiều, rất khỏ để mở rộng, người khác vào làm để theo kịp rất mất thời gian.
 

Similar threads

rimbb
Dự án ngăn triều 10.000 tỉ đồng "đứng hình" gần 4 năm ngay trước vạch đích
Replies
10
Views
756
Bình nước Lavie
Bình nước Lavie
Khonanchua
ExxonMobil 'bật đèn xanh' cho dự án khai thác dầu trị giá 12,7 tỷ USD ngoài khơi Guyana
Replies
8
Views
562
beophe9999
beophe9999
Q
XIN LỜI KHUYÊN VỀ CON ĐƯỜNG SỰ NGHIỆP
Replies
11
Views
1K
ReallOM92
ReallOM92
votrongsu
Học ngành Xây dựng ra trường, nhiều cơ hội việc làm thu nhập trên 20 triệu/tháng
6 7 8
Replies
149
Views
6K
HondaTsubasa
HondaTsubasa
GloryJack
Suntory Pepsico khởi công nhà máy lớn nhất châu Á tại Long An
2 3
Replies
43
Views
3K
bricks on the wall
bricks on the wall

Share this page

Back
Top