Kiến trúc thư mục của 1 project?

Câu 1:
Tuỳ project có, tuỳ project không.
Điểm lợi của phân chia module là mỗi module có mô hình riêng: MVC, MVVM, Flux,… Còn nếu project theo MVC ngay từ đầu thì sẽ bó buộc mô hình MVC cho các tính năng từ đơn giản đến phức tạp. Ví dụ mục các modal view chỉ gồm các radio button thì mình sẽ viết không kiến trúc.

Câu 2:
hook thường dùng trong các CMS, vì CMS bị bó buộc vào database schema, code có sẵn nên phải dùng “hook” để thêm tính năng.
Các framework vẫn hỗ trợ hook, cái tên có thể khác (middleware, interceptor, filter,…) nhưng không nên lạm dụng nhiều, vì nó cho thấy bản thiết kế của project không tốt và linh hoạt. Lúc đó nên xem xét lại các thành phần (module) của project phản ánh chính xác domain hay không.

Đó là một số ý kiến của mình.

vậy có cách nào để xây dựng 1 ứng dụng mà không bị quá phụ thuộc vào database schema không anh , kiểu như mình dùng 1 module trung gian để ứng dụng và database giao tiếp với nhau và module này có khả năng thay đổi linh hoạt ? .
Và nếu không dùng kĩ thuật hook function thì mình dùng cách nào để can thiệp vào code đã viết trước ( hix cái này em thấy hơi sai vì code được viết trước thì đã test và đóng gói mà giờ mình can thiệp vào thì kiểu như phá vở chương trình rất dễ gây ra bug @@) …

Phần này thì mỗi framework, mỗi CMS có câu trả lời khác nhau, nên không thể nói chung chung được. Topic của bạn là PHP nên mình chỉ nêu 1 CMS là WordPress và 1 web framework phân chia dạng module là Zend Framework. Kiến thức 2 phần thì mình không có nhiều lắm.

Phía WordPress thì khi sau khi đổi các info về database và auth trong wp_config.php, đăng nhập vào /wp_admin thì tự động website tạo database sẵn cho mình, mỗi WordPress website đều có database giống nhau. Ngoài ra WordPress cũng cung cấp sẵn code truy vấn database và hiển thị theo blog cho mình. Việc chỉnh sửa source code trực tiếp thường không khuyến khích. Vì vậy, ngoài chỉnh sửa theme, dev thường sử dụng ActionHook hay FilterHook để thay đổi các thực thi một số function có sẵn của CMS.

Bên Zend Framework, như các PHP framework khác, thì không có tự tạo database schema, mà dev tạo trước. Sau đó dev viết code + test case. Sau này có bug chỗ nào chỉ sửa chỗ đó thôi. Ý cá nhân mình thì thấy Zend phân chia module và class chi tiết, rõ hơn các framework khác của PHP: Entity, TableGateway, Query, Form, View Helper, Partial View, Layout,… Route cũng có nhiều cách sửa route, từ literal, dynamic route, regular expression, đến custom function có hết. Nếu có 1 bug nào đó xảy ra thì mình nghĩ cũng chẳng cần hook làm gì.

Còn nếu bạn dùng micro framework như Slim chẳng hạn, thì chỉ cần phân tích business domain kĩ vào, chia thành nhiều module và class tách biệt ra.

em thấy thường chia ra thành các tầng cho dễ xử lý mà ví dụ mô hình 3 layer chả hạn .một tầng dùng để thao tác lấy db .tầng khác dùng để xử lý code logic .rồi cuối cùng thì web cũng chỉ view lên thôi .hay thêm một pj nữa chuyên về xử lý các hàm comon dùng chung như gửi mail hay ghi log chả hạn

Kiến trúc 3-layer thường ở bên Java, nhưng thớt tag bên PHP nên mình không nói tới thôi.
Chứ lấy ví dụ về JavaEE thì mình sẽ nói về nó.

Mình nói lại lần nữa vậy: thớt hỏi bên PHP

Đừng đem kiến trúc bên C#, Java, hay mấy cái xa hơn như desktop, mobile vào.
Trước đây có 1 topic do đem architecture từ cả đống framework vào làm nó rối luôn.
Nhờ các bạn giải đáp thắc mắc về mô hình MVC?