Mimari Prensipler

Mimari Prensipler

Denomas'ın tüm ürünleri ve altyapısı aşağıdaki mimari prensipler üzerine inşa edilir. Mimari, "Önce Teknik Temel (Foundation First)" felsefesine dayanır. Müşteriye sunulacak özellikler geliştirilmeden önce tüm geliştirme ve otomasyon altyapısı mükemmelleştirilir.

Teknoloji Yığını (Technology Stack)

1. API-First

Her ürün ve hizmet, önce API olarak tasarlanır. UI, API'nin bir tüketicisidir.

• Tüm API'ler OpenAPI 3.0+ spesifikasyonu ile dokümante edilir
• API versiyonlaması zorunludur (/api/v1/, /api/v2/)
• Rate limiting ve authentication her endpoint'te bulunur
• API tasarımı, implementasyondan önce review edilir

Gerçek Örnek — Siber Sigorta Tarama API:

POST /api/v1/security_scan
Content-Type: application/json

{
  "target_url": "https://example.com",
  "scan_type": "quick",
  "callback_url": "https://odoo.internal/api/scan_callback"
}

Bu endpoint, Odoo Controller tarafından Güvenlik Tarama Servisi'ni (Docker konteyner) tetikler. Sonuçlar JSON olarak döner, Odoo risk skoru hesaplar ve otomatik olarak crm.lead kaydı oluşturur.

2. Infrastructure as Code (IaC)

Tüm altyapı, kod olarak tanımlanır ve versiyon kontrolünde tutulur.

• Ansible — Konfigürasyon yönetimi ve deployment
  • Standart Ansible rolleri: denomas-base, denomas-monitoring, denomas-security, denomas-backup
  • Tüm roller code.denomas.com/ansible/roles/ altında versiyon kontrolündedir
  • Playbook'lar idempotent olmalı ve molecule ile test edilmelidir
• Terraform — Cloud kaynak yönetimi (AWS, Proxmox, VMWare provizyon)
• Docker / Docker Compose — Konteynerizasyon
  • Başlangıç mimarisi: Docker Compose ile tek sunucu
  • Ölçeklenme planı: Kubernetes'e geçiş (auto-scaling, self-healing)
• Makefile — Karmaşık geliştirici ortamını basit komutlarla yönetir (make setup, make start, make test)
• Manuel altyapı değişikliği yapılmaz; tüm değişiklikler MR üzerinden gelir

# Örnek: Yeni ortam başlatma
make setup          # Bağımlılıkları yükle, .env oluştur
make start          # Docker Compose ile tüm servisleri başlat
make test           # Tüm testleri çalıştır
make deploy-staging # Staging ortamına deploy

3. Zero Trust

Ağ içerisinde bile güven varsayılmaz. Her istek doğrulanır.

• mTLS ile servisler arası iletişim
• RBAC ile en az yetki (least privilege) prensibi — Odoo'nun standart ACL ve Record Rules yapısı en katı şekilde uygulanır
• Tüm erişim logları merkezi olarak toplanır (Wazuh)
• Düzenli erişim denetimleri yapılır
• Sır Yönetimi (Secrets Management):
  • API anahtarları, veritabanı parolaları asla kodun içinde (hardcoded) yer almaz
  • Geliştirme ortamı: .env dosyaları (.gitignore'da zorunlu)
  • CI/CD ortamı: GitLab CI/CD Variables (Protected + Masked)
  • Canlı ortam: HashiCorp Vault veya GitLab CI/CD Variables
• Otomatik Kalite Kapısı, SQL injection ve XSS gibi bilinen açıkları koda girmeden engeller

4. Modülerlik

Ürünler bağımsız modüllere ayrılır:

• Her modül bağımsız deploy edilebilir
• Modüller API üzerinden iletişim kurar
• Gevşek bağlı, sıkıca tanımlanmış arayüzler
• 700+ modül bu prensiple yönetilir

Hibrit Odoo Çekirdeği Mimarisi

Platform, Hibrit ve Genişletilebilir Odoo Çekirdeği Mimarisi üzerine kuruludur:

Multi-Tenant Mimari

Çoklu müşteri izolasyonu için:

• Her müşteri için izole veritabanı şeması (PostgreSQL schema-based isolation)
• RBAC ile tenant bazlı erişim kontrolü
• Tenant-aware API middleware
• Partner portalı ve bayi portalı ayrı Odoo Website instance'ları olarak çalışır

5. Mimari Karar Süreci (Architecture Decision Records)

Her teknik karar, "Mimari Analiz ve Karar Verme Süreci (SOP v6.0)" belgesine uyularak verilir. Bu süreç, "Kullan > Yükselt > Genişlet > İnşa Et" hiyerarşisini zorunlu kılar.

Karar Hiyerarşisi

Kantitatif Karar Matrisi

Her mimari karar için docs/decisions/decision_log_[konu].md dosyasında şu matris doldurulur:

Alınmış Mimari Kararlar Örnekleri

6. Resilience (Dayanıklılık)

Sistemler, arızaya hazır tasarlanır:

• Circuit breaker pattern
• Graceful degradation
• Otomatik retry mekanizmaları
• Canary deployment ve otomatik rollback
• Evrensel Connector Mimarisi — Bir sağlayıcıda sorun yaşandığında başka bir sağlayıcıya geçişi kolaylaştıran esnek yapı

7. Gözlemlenebilirlik (Observability)

Her sistem, izlenebilir ve hata ayıklanabilir olmalıdır:

• Prometheus metrikleri — Odoo ve PostgreSQL için özel exporter'lar
• Yapılandırılmış loglama — Tüm bileşenler loglarını JSON formatında stdout'a yazar
• Merkezi log toplama — Fluentd ile Docker/Kubernetes log'ları toplanır ve Wazuh'a gönderilir
• Dağıtık tracing (OpenTelemetry)
• Grafana panoları — Veritabanı bağlantı sayısı, yavaş sorgular, aktif kullanıcı sayısı gibi kritik metrikler
• Alerting ve on-call süreçleri

8. Ölçeklenebilirlik

Kubernetes'e geçişte kazanılacak yetenekler:

• Auto-scaling — Yoğun saatlerde Odoo web sunucusu pod sayısı otomatik artar
• Self-healing — Çöken servisler otomatik yeniden başlatılır
• Rolling Updates — Sıfır kesinti ile güncelleme

İlgili Sayfalar

• Mühendislik Genel Bakış
• Mühendislik
• Hibrit Bulut Stratejisi
• İzleme ve Gözlemlenebilirlik
• Güvenlik Yaklaşımı
• CI/CD Pipeline
• Kod Kalitesi

Sayfa kaynağını görüntüle - Bu sayfayı düzenle - please contribute.