🏛 Toàn tập thuật ngữ về mô hình Monolith trong phần mềm
Published on: August 08, 2025
Last updated: August 08, 2025 Xem trên toàn màn hình
Last updated: August 08, 2025 Xem trên toàn màn hình
Recommended for you
- 04 Jan 2023
Phát triển phần mềm linh hoạt theo mô hình Big Bang 571 - 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 501
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 416
- 03 May 2022 Mô hình Hybrid Agile là gì? 404
- 19 Aug 2024 Kiểm toán công nghệ thông tin (IT Audit) - Nghề mới mẻ ở Việt Nam 365
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 362
- 02 Jan 2024 Domain Engineering là gì? 350
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 320
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 310
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 302
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 286
- 01 Sep 2023 "Data steward" là gì? 280
- 05 Aug 2024 Giải mã 10 sai lầm về quản lý thay đổi 259
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 251
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 219
- 02 Mar 2018 Tại sao ví Scrum như dòng điện xoay chiều? 219
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 184
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 173
- 08 Apr 2024 Hiệu ứng Matthew: Tác động và Ứng dụng trong Chuyển đổi Số và Công nghệ tại Việt Nam 162
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 160
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 151
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 149
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 129
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 87
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 85
- 08 Aug 2019 10 lý do tại sao việc sử dụng và vận hành phần mềm điều hành doanh nghiệp không được hiệu quả 79
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 45
- 26 Mar 2025 Từ điển tất cả các chức danh trong lĩnh vực CNTT và Chuyển Đổi Số 43
- 01 Jun 2025 Thiết Kế Hướng Miền (Domain-Driven Design) hình thành như thế nào trong kiến trúc Lưới Dữ Liệu (Data Mesh)? 24
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 21
- 01 Apr 2025 CTO ra quyết định như thế nào? 20
Mô hình Monolith (nguyên khối) là một trong những kiến trúc phần mềm cổ điển, nơi toàn bộ ứng dụng được xây dựng và triển khai như một khối duy nhất. Dưới đây là danh sách các thuật ngữ quan trọng giúp bạn hiểu sâu về mô hình này.
Monolithic Architecture
- Định nghĩa: Kiến trúc phần mềm mà tất cả các thành phần (modules) của ứng dụng được gộp chung vào một codebase, chạy như một tiến trình (process) duy nhất.
- Giải thích dễ hiểu: Tưởng tượng một tòa nhà chung cư cũ — tất cả mọi thứ chung một kết cấu, khó tách rời.
- So sánh: Ngược lại, Microservices Architecture tách thành nhiều dịch vụ nhỏ, triển khai độc lập.
Single Codebase
- Định nghĩa: Toàn bộ mã nguồn của ứng dụng được quản lý trong một kho code duy nhất.
- Ưu điểm: Dễ quản lý lúc nhỏ.
- Nhược điểm: Khi lớn lên, thay đổi một phần nhỏ có thể ảnh hưởng toàn hệ thống.
Tight Coupling (Kết nối chặt chẽ)
- Định nghĩa: Các module phụ thuộc mạnh vào nhau, thay đổi một module có thể kéo theo sửa các module khác.
- Ví dụ: Thay đổi logic đặt hàng có thể yêu cầu chỉnh cả module thanh toán và kho hàng.
Shared Database
- Định nghĩa: Tất cả các phần của ứng dụng truy cập chung một cơ sở dữ liệu.
- Ưu điểm: Dễ đồng bộ dữ liệu.
- Nhược điểm: Rủi ro nghẽn cổ chai, khó mở rộng độc lập.
Single Deployment Unit
- Định nghĩa: Ứng dụng được build và triển khai dưới dạng một gói duy nhất (JAR, WAR, EXE, Docker image...).
- Hệ quả: Dù chỉ sửa một tính năng nhỏ, vẫn phải build & deploy lại toàn bộ.
Scalability Limitation (Giới hạn mở rộng)
- Định nghĩa: Chỉ có thể mở rộng toàn bộ ứng dụng theo chiều ngang (scale-out) hoặc chiều dọc (scale-up), không thể mở rộng từng phần riêng biệt.
- Ví dụ: Muốn tăng sức mạnh xử lý của module thanh toán, buộc phải scale cả ứng dụng.
Code Entanglement (Rối mã)
- Định nghĩa: Khi code của các module đan xen, khó tách biệt.
- Hệ quả: Khó refactor hoặc tách sang microservices.
Monolith First Approach
- Định nghĩa: Chiến lược khởi đầu dự án với kiến trúc Monolith để phát triển nhanh MVP, sau đó chuyển sang Microservices khi cần.
- Ưu điểm: Nhanh ra sản phẩm, ít chi phí ban đầu.
Big Ball of Mud
- Định nghĩa: Thuật ngữ chỉ một hệ thống Monolith đã mất cấu trúc, code lộn xộn, thiếu kiến trúc rõ ràng.
- Nguyên nhân: Nhiều năm phát triển mà không refactor hoặc tái kiến trúc.
Refactoring Monolith
- Định nghĩa: Quá trình cải tiến cấu trúc code của Monolith mà không thay đổi hành vi bên ngoài.
- Mục tiêu: Chuẩn bị cho việc tách sang microservices hoặc modular monolith.
Modular Monolith
- Định nghĩa: Kiến trúc Monolith nhưng được thiết kế thành các module độc lập rõ ràng bên trong, giảm tight coupling.
- Ưu điểm: Dễ bảo trì, có thể tách dần thành microservices.
Deployment Bottleneck
- Định nghĩa: Vấn đề khi mọi thay đổi đều phải chờ build & deploy nguyên khối, làm chậm quy trình CI/CD.
- Hệ quả: Đội ngũ phát triển bị “nghẽn” khi cần ra tính năng nhanh.
Monolith to Microservices Migration
- Định nghĩa: Quá trình tách một ứng dụng nguyên khối thành nhiều dịch vụ nhỏ.
- Thách thức: Cần quản lý dữ liệu phân tán, giao tiếp qua API, và đồng bộ tính năng.
Service Layer in Monolith
- Định nghĩa: Tầng dịch vụ trung gian giữa UI và Database trong Monolith.
- Vai trò: Tách logic nghiệp vụ ra khỏi giao diện và dữ liệu, giảm phần nào sự rối mã.
Domain-Driven Design (DDD) in Monolith
- Định nghĩa: Áp dụng DDD vào Monolith để chia domain rõ ràng.
- Lợi ích: Tạo nền tảng tốt nếu sau này cần tách sang microservices.
Single Point of Failure (SPOF)
- Định nghĩa: Nếu Monolith gặp sự cố, toàn bộ hệ thống dừng hoạt động.
- Ví dụ: Một bug nhỏ cũng có thể làm sập toàn bộ website (hiệu ứng cánh bướm).
Horizontal vs Vertical Scaling
- Horizontal Scaling: Thêm nhiều server để chạy song song.
- Vertical Scaling: Nâng cấp phần cứng server hiện tại.
- Monolith: Thường bị giới hạn trong cả hai hình thức này.
Monolithic Frontend
- Định nghĩa: Toàn bộ giao diện được gói thành một khối duy nhất (ví dụ: Single Page Application nguyên khối).
- Nhược điểm: Khó chia nhỏ theo tính năng hoặc nhóm phát triển.
Transaction Management in Monolith
- Định nghĩa: Xử lý giao dịch (transaction) dễ dàng hơn vì tất cả trong cùng một database và tiến trình.
- Ưu điểm: Ít vấn đề phân tán.
- Nhược điểm: Khó mở rộng sang phân tán.
Legacy Monolith
- Định nghĩa: Hệ thống Monolith đã cũ, khó bảo trì, thường viết bằng công nghệ lỗi thời.
- Vấn đề: Tốn nhiều chi phí nâng cấp, rủi ro cao khi sửa.
[{"displaySettingInfo":"[{\"isFullLayout\":false,\"layoutWidthRatio\":\"\",\"showBlogMetadata\":true,\"showAds\":true,\"showQuickNoticeBar\":true,\"includeSuggestedAndRelatedBlogs\":true,\"enableLazyLoad\":true,\"quoteStyle\":\"1\",\"bigHeadingFontStyle\":\"1\",\"postPictureFrameStyle\":\"1\",\"isFaqLayout\":false,\"isIncludedCaption\":false,\"faqLayoutTheme\":\"1\",\"isSliderLayout\":false}]"},{"articleSourceInfo":"[{\"sourceName\":\"\",\"sourceValue\":\"\"}]"},{"privacyInfo":"[{\"isOutsideVietnam\":false}]"},{"tocInfo":"[{\"isEnabledTOC\":false,\"isAutoNumbering\":true,\"isShowKeyHeadingWithIcon\":true}]"},{"termSettingInfo":"[{\"showTermsOnPage\":true,\"displaySequentialTermNumber\":true}]"}]
Nguồn
{content}
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Mới cập nhật
