Project Architecture Design for 1C-Bitrix
Architectural decisions in a Bitrix project are made once — and they stay with the project for years. The choice between a monolithic template and a component-based architecture, between storing data in iblocks and HL-blocks, between standard components and custom development — each of these decisions determines maintenance cost, scalability, and the speed of adding new features two or three years down the road. Architecture design is a phase that cannot be skipped if the project is intended to be long-lived.
Architectural Layers of a Bitrix Project
Bitrix has several layers, and decisions at each level affect the others.
Data layer: iblocks, HL-blocks, custom tables
iblocks (b_iblock_element, b_iblock_element_property) are a flexible tool, but at a cost: the EAV schema does not scale well at large volumes. Key decisions at this layer:
- What data is stored in iblocks, what in HL-blocks, and what in custom tables via D7 ORM (
\Bitrix\Main\ORM\Data\DataManager) - The structure of iblock types and their grouping
- The trade offers schema: one offer iblock for everything or separate ones per category
Logic layer: components vs. custom code
Standard Bitrix components (bitrix:catalog.section, bitrix:sale.order.ajax, bitrix:form) cover common scenarios. Beyond them, you choose: extend an existing component via a template, create a custom component (CBitrixComponent), or write logic in a D7 controller (\Bitrix\Main\Engine\Controller).
The principle: if business logic is project-specific and not reusable, it should not live in a component template. A template is presentation only.
Caching layer
The architectural decision here is what data gets cached and how it is invalidated. Options in Bitrix:
-
BXCache/CPHPCache— file-based cache for components -
TaggedCache(\Bitrix\Main\Data\TaggedCache) — tag-based invalidation -
CacheD7 (\Bitrix\Main\Data\Cache) — unified cache with memcached/Redis support - Composite cache — static HTML for anonymous users
Frontend layer
Bitrix supports multiple approaches: classic PHP templates with jQuery, Bitrix components with BX.ajax, and a modern stack — Vue/React via REST API or components with bitrix:ui.*. The choice affects maintainability: a frontend developer who joins for support must be able to navigate what you chose.
Multi-site and Multi-regional Architecture
If the project spans multiple regions or languages, the architectural decision is made at the start. Bitrix supports:
- Multiple sites in a single core with a shared database (
b_site) - Language versions via the
languagesmechanism in themainmodule - Regional sites with different domains and shared content
A wrong choice (e.g., separate catalogs per region instead of one with regional pricing) leads to data duplication and synchronization issues.
Case Study: e-commerce Project Architecture Overhaul
An industrial equipment distributor, 2019. The project was developed without an explicit architectural plan: 4 catalog iblocks for different product categories, each with its own set of string properties, custom business logic in init.php, and component templates with business logic embedded inside.
By 2022: 45,000 elements total, adding a new property required changes in 4 places, the filter could not work across properties from different iblocks, and the 1C sync was a custom 2,000-line script with no documentation.
What was done during refactoring:
- Merged 4 catalog iblocks into one with a unified property schema via HL-blocks
- Moved business logic from templates into D7 components and service classes in
local/lib/ - Broke up the
init.phplogic into event handlers registered viaAddEventHandler - Configured a facet index on the unified iblock — the filter started working correctly
- Replaced the custom script with standard 1C CommerceML exchange
Deliverables at the Architecture Design Stage
- Data structure diagram: iblocks, HL-blocks, relationships
- Page component composition diagram
- Caching and invalidation schema
- Integration architecture: 1C, CRM, third-party services
- Multi-site and multilingual decisions
- Justification for the choice of Bitrix edition and modules
Design timeline: from 1 week for a small project to 4–6 weeks for an enterprise project with multiple integrations and a multi-site structure.