Kiến trúc 1C Enterprise: Configuration Object và cách platform hoạt động
Nếu bạn là developer quen với .NET, Java hay bất kỳ ngôn ngữ hướng đối tượng nào, lần đầu mở 1C Configurator lên có thể sẽ gặp cảm giác: "Cái này là gì vậy? Sao không thấy database schema đâu cả?"
Đó là câu hỏi đúng. Và bài này sẽ trả lời nó.
1C Enterprise không để bạn viết SQL, không để bạn tự tạo bảng, không để bạn đặt foreign key. Thay vào đó, nó cung cấp một tầng trừu tượng gọi là Configuration Object — và toàn bộ ứng dụng 1C được xây từ các object này. Hiểu cơ chế này là điều kiện tiên quyết trước khi đọc bất kỳ bài nào tiếp theo trong series.
Configuration Object là gì — và tại sao nó không giống class thông thường
Trong OOP thông thường, bạn tạo một class Customer, định nghĩa property, rồi tự lo việc lưu nó xuống database — dù là dùng Entity Framework, Hibernate hay viết raw SQL.
1C làm khác. Bạn không tạo class. Bạn tạo Configuration Object thuộc một loại xác định — ví dụ Catalog (danh mục) — và platform tự biết nó cần lưu như thế nào, hiển thị như thế nào, và cho phép tìm kiếm ra sao.
Nói cách khác: Configuration Object là blueprint, còn platform là người hiện thực hóa nó.
Khi bạn tạo một Catalog tên Customers trong Configurator, 1C tự động:
Tạo bảng tương ứng trong database (thường là SQL Server hoặc PostgreSQL)
Tạo form danh sách và form chỉnh sửa mặc định
Cung cấp API để query, tạo mới, cập nhật object đó trong code
Bạn không viết một dòng SQL nào. Bạn không thiết kế schema. Bạn chỉ mô tả cấu trúc dữ liệu nghiệp vụ — và platform lo phần còn lại.
Các loại Configuration Object chính — bản đồ của hệ thống 1C
Đây là phần quan trọng nhất cần nắm trước khi làm bất cứ điều gì trong 1C. Toàn bộ kiến trúc nghiệp vụ được xây từ các loại object sau:
Catalog (Справочник) — lưu danh mục tham chiếu: khách hàng, nhà cung cấp, sản phẩm, nhân viên. Tương đương với lookup table hay master data trong database truyền thống. Catalog hỗ trợ cấu trúc phân cấp (hierarchy) tích hợp sẵn — không cần tự làm cây parent-child.
Document (Документ) — ghi nhận sự kiện nghiệp vụ xảy ra tại một thời điểm: hóa đơn bán hàng, phiếu nhập kho, phiếu lương. Document luôn có header (mã, ngày, người tạo) và có thể có tabular section (dòng chi tiết). Sau khi "post" một Document, nó tạo ra movement trong các Register — đây là cơ chế cốt lõi của 1C.
Register (Регистр) — ghi nhận số liệu thay đổi theo thời gian. Có 4 loại: Accumulation Register (số dư tích lũy như tồn kho), Accounting Register (kế toán double-entry), Calculation Register (tính lương theo kỳ), Information Register (thông tin thời điểm như tỷ giá). Nếu bạn từng làm event sourcing, Register gần với khái niệm event log hơn là một bảng dữ liệu thông thường.
Report và Data Processor — Report là module truy vấn và xuất dữ liệu ra màn hình hoặc file. Data Processor là module xử lý nghiệp vụ phức tạp không gắn với một object cụ thể — ví dụ: import dữ liệu từ Excel, chạy batch process.
Business Process và Task — quản lý workflow. Ít dùng hơn nhưng tồn tại sẵn trong nền tảng.
Object | Tương đương gần nhất trong hệ thống thông thường |
|---|---|
Catalog | Master data table + CRUD UI |
Document | Transaction record + business logic |
Accumulation Register | Event log / ledger table |
Report | Stored procedure + UI render |
Data Processor | Background service / batch job |
Metadata Class là gì — cách 1C "biết" mỗi object là loại gì
Khi bạn tạo một Catalog Customers, thứ bạn đang làm thực chất là tạo một metadata definition — một mô tả về object đó: tên, các attribute (field), các tabular section, các form liên quan.
Tổng hợp toàn bộ các định nghĩa này tạo thành Metadata của configuration. Và mỗi loại object (Catalog, Document, Register...) là một Metadata Class.
Trong code 1C (ngôn ngữ 1C:Enterprise Script), bạn có thể truy cập metadata lúc runtime:
// Lấy metadata của Catalog Customers
Meta = Metadata.Catalogs.Customers;
// Meta.Name = "Customers"
// Meta.Attributes — danh sách tất cả field đã định nghĩaĐiều này có nghĩa là: cấu trúc của ứng dụng là dữ liệu, không phải code cứng. Bạn có thể viết code generic duyệt qua toàn bộ Catalog trong hệ thống mà không cần biết trước tên của từng cái. Đây là nền tảng cho rất nhiều pattern trong 1C development.
Tại sao approach này bỏ qua việc thiết kế database schema
Đây là điểm mà developer đến từ thế giới SQL thường phải điều chỉnh tư duy nhất.
Trong hệ thống thông thường, khi bạn cần thêm field DiscountRate vào bảng Customers, bạn phải: viết migration script, cập nhật ORM model, cập nhật API, cập nhật UI. Bốn bước, có thể nhiều hơn nếu có test.
Trong 1C: bạn mở Configurator, thêm attribute DiscountRate vào Catalog Customers, chọn kiểu dữ liệu, lưu lại, cập nhật database bằng nút "Update database configuration". Platform tự sinh ALTER TABLE. Form mặc định tự hiển thị field mới. Xong.
Lý do điều này hoạt động được là vì 1C tạo ra một mapping layer hoàn toàn giữa Configuration Object và physical database table. Tên bảng trong SQL không phải Customers — nó là _Reference42 hay tương tự, do platform quản lý. Developer không bao giờ cần biết tên đó.
Đây không phải là "magic" — đây là một tradeoff có chủ đích: bạn nhượng bộ quyền kiểm soát schema để đổi lấy tốc độ phát triển và tính nhất quán. Với phần mềm kế toán nghiệp vụ phức tạp, tradeoff này thường có lợi.
Nhìn toàn cảnh: configuration là gì trong 1C
Một Configuration trong 1C là toàn bộ tập hợp các Configuration Object bạn định nghĩa — Catalog, Document, Register, Report... — cộng với code, form, và role (phân quyền).
Khi bạn deploy một ứng dụng 1C, bạn đang deploy một Configuration lên 1C Server. Server kết hợp với platform runtime để chạy ứng dụng đó. Database chỉ là storage — logic nằm trong Configuration, không nằm trong database.
Một hệ quả thực tế: backup 1C đúng cách là backup cả Configuration lẫn database, không phải chỉ database như nhiều hệ thống khác.
Tổng kết — những điều cần nhớ trước khi đọc bài tiếp theo
Nếu bạn chỉ nhớ ba điểm từ bài này:
Mọi thứ trong 1C đều là Configuration Object — Catalog, Document, Register là các loại cơ bản nhất.
Platform tự quản lý database schema — bạn mô tả cấu trúc nghiệp vụ, platform lo phần còn lại.
Metadata là first-class citizen — bạn có thể truy cập và duyệt cấu trúc ứng dụng lúc runtime, không chỉ lúc compile.
Các bài tiếp theo trong series sẽ đi sâu vào từng loại object: Catalog hoạt động thế nào, Document posting là gì, Register movement được tạo ra như thế nào. Tất cả sẽ ăn khớp hơn khi bạn đã có bức tranh kiến trúc tổng thể này.
Nếu bạn đang bắt đầu tìm hiểu 1C Enterprise và muốn có lộ trình học bài bản, xem thêm tại tedu.com.vn.
Tác giả: TEDU
Chú ý: Tất cả các bài viết trên TEDU.COM.VN đều thuộc bản quyền TEDU, yêu cầu dẫn nguồn khi trích lại trên website khác.
Tags:
Bài viết liên quan
1C Enterprise là gì? Tại sao Developer nên quan tâm đến nền tảng Lowcode này
1C Enterprise không phải phần mềm kế toán — đây là lowcode platform để build ứng dụng quản trị doanh nghiệp. Tìm hiểu lý do developer nên quan tâm.
Đọc thêm
1C:Enterprise là gì? Nền tảng Low-Code để phát triển ERP và hệ thống quản trị doanh nghiệp
1C:Enterprise là nền tảng Low-Code mạnh mẽ giúp doanh nghiệp và developer xây dựng nhanh các hệ thống ERP, CRM, kế toán và quản trị doanh nghiệp. Tìm hiểu kiến trúc, cách hoạt động và lợi ích của 1C:Enterprise trong phát triển ứng dụng doanh nghiệp.
Đọc thêm