Trong một hệ thống lớn hơn, dễ dàng hơn nhiều để:
Chia sẻ tính năng và mã. Bạn sẽ phát minh lại bánh xe ít hơn một chút. Ví dụ: nếu bạn có mười ứng dụng phải có quyền truy cập vào cơ sở dữ liệu, bạn phải chỉ định chuỗi kết nối trong tất cả chúng , tức là mười lần. Hoặc bạn phải tạo một thư viện riêng và tham khảo lại mười lần nữa.
Hợp nhất các quy trình công việc , bao gồm cả quá trình triển khai.
Quản lý hệ thống: ít ứng dụng để quản lý thường dễ dàng hơn .
Thống nhất trải nghiệm người dùng . Khi một nhân viên phải đối phó với mười ứng dụng khác nhau, anh ta có thể dễ dàng bị mất: ứng dụng nào để chạy A? Trong ứng dụng nào có sẵn tùy chọn B? Nhưng đừng quá khích . Không ai sẽ đánh giá cao Word, PowerPoint, Outlook, Publisher, Visio, Project và Groove như một ứng dụng nguyên khối duy nhất.
Mặt khác, trong một loạt các hệ thống nhỏ, bạn sẽ thấy rằng:
Bạn có thể từ bỏ toàn bộ hệ thống nếu bạn không cần nó nữa. Hoặc bắt đầu lại từ đầu nếu codebase trở nên không sử dụng được theo thời gian. Điều này tất nhiên chỉ đúng nếu các hệ thống khác không dựa vào hệ thống này hoặc nếu giao diện đủ nhẹ để dễ dàng viết lại trong phiên bản mới.
Bạn có thể thành lập một nhóm các nhà phát triển mới và mong muốn họ hiểu được cơ sở mã hiện tại trong thời gian ngắn hơn . Nếu đó là một phần của một dự án lớn, rất có thể họ sẽ cần nhiều thời gian hơn, trừ khi toàn bộ cơ sở mã lớn được thực hiện cực kỳ chuyên nghiệp và được tái cấu trúc rất tốt (tôi chưa từng thấy những cơ sở mã hóa như vậy trong đời).
Các quản trị viên hệ thống sẽ có thể di chuyển các ứng dụng dễ dàng hơn . Mặt khác, hệ thống lớn hơn có thể mở rộng tốt trên nhiều máy chủ hoặc không.
Các nhà phát triển có thể di chuyển codebase sang các tiêu chuẩn mới dễ dàng hơn . Di chuyển một codebase lớn luôn luôn đáng sợ. Thay vào đó, khi bạn phải đối phó với một codebase nhỏ, sau đó là cái khác, rồi cái khác, v.v., nó trở nên ít đáng sợ hơn.
Điều này đang được nói, so sánh như vậy chỉ hoạt động trong các trường hợp chung, nhưng quyết định của bạn phải được lấy không phải từ nhóm, mà từ tài sản công ty của bạn. Nó được tổ chức như thế nào? Có nhiều nhóm phát triển nhỏ hoặc một vài nhóm lớn? Có hướng dẫn nghiêm ngặt về phong cách mã hóa và những thứ tương tự?
Nó cũng phụ thuộc vào chính ứng dụng. Ví dụ: sẽ vô lý khi gửi tất cả các ứng dụng Microsoft Office dưới dạng một ứng dụng. Nhưng nó cũng sẽ ảnh hưởng đến năng suất, ví dụ, tách Adobe Photoshop trong một ứng dụng để vẽ và một ứng dụng khác để chỉnh sửa ảnh. IMO, quyết định hợp nhất hoặc tách sản phẩm phải là quyết định kinh doanh, không phải là quyết định thuần túy về mặt kỹ thuật.
Cuối cùng, tôi cũng muốn trả lời bình luận thứ hai của câu hỏi ban đầu:
Tôi cho rằng việc liên kết dữ liệu trong một ứng dụng ít tốn công sức hơn so với liên kết dữ liệu giữa các ứng dụng
Điều đó không phải lúc nào cũng đúng. Nếu bạn đang xử lý ví dụ với .NET, sẽ không có gì lạ khi gửi một ứng dụng duy nhất nơi các thành phần khác nhau đang trao đổi thông qua WCF. Trong trường hợp này, điều này có thể so sánh với một tập hợp các ứng dụng riêng biệt giao tiếp qua WCF.
Tất nhiên, khi bạn phải xử lý nhiều ứng dụng, bạn phải thiết lập một số cách để chúng giao tiếp, trong khi việc có một ứng dụng nguyên khối duy nhất không buộc bạn phải làm điều đó. Nhưng bạn có thực sự có thể viết một ứng dụng nguyên khối lớn không?