ArchDB : schémas BD modulaires en tant que code

Ingénierie de schéma modulaire avec ArchDB : Modèles, Paquets et Modélisation Déclarative

ArchDB vous permet de décrire la structure de la base de données de manière déclarative dans des fichiers .adb, en l'intégrant à un dépôt Git. Les modèles éliminent la duplication des champs d'audit et d'identification, tandis que les Paquets décomposent un monolithe en modules indépendants. Le modèle génère du DDL, de la documentation et des diagrammes. Cette approche accélère les revues de modifications et la synchronisation avec les ORM.

// Core.adb - modèles de base
Package com.example.ecommerce.Core

Template IdentifiableUuid {
  id uuid [pk, default: `gen_random_uuid()`]
}

Template Auditable {
  created_at timestamp [not_null, default: `now()`]
  created_by uuid [ref: > User.id, nullable]
  updated_at timestamp [default: `now()`]
  updated_by uuid [ref: > User.id, nullable]
  indexes {
    idx_created_at (created_at)
  }
}

Template BusinessEntity extends IdentifiableUuid, Auditable {
  version_no integer [default: 1]
  status varchar(50) [default: 'active']
}

Modèles pour la réutilisabilité

Les modèles sont composés via extends, héritant des champs et des index. BusinessEntity combine identification, audit et versioning. L'appliquer à une table User ajoute automatiquement tous les champs :

• UUID id avec PK et un générateur par défaut
• Champs created_at/updated_at avec index
• version_no pour le verrouillage optimiste

Les vérifications et les index uniques sont configurés au niveau de la table :

Table User extends BusinessEntity {
  email varchar(255) [unique, not_null]
  password_hash text [not_null]
  checks {
    `char_length(password_hash) >= 8`
  }
}

Les Groupes Logiques améliorent la visualisation dans la documentation en attribuant des couleurs et des descriptions.

Décomposition modulaire via Paquet

Chaque fichier .adb est un Paquet séparé avec des imports. Product.adb importe Core.adb pour étendre BusinessEntity :

// Product.adb
Package com.example.ecommerce.Product
import "com.example.ecommerce.Core.adb" version 3.4.0

export Product as "com.example.ecommerce.Product" version 3.6.0

Table Product extends Core.BusinessEntity {
  sku varchar(50) [unique, not_null]
  price decimal(12, 2) [not_null]
  stock_quantity integer [default: 0]
  available_quantity integer [generated: `stock_quantity - reserved_quantity`]
  checks {
    `price >= cost_price`
    `reserved_quantity <= stock_quantity`
  }
}

Les champs générés sont calculés au niveau de la base de données. Relation décrit les relations M:N :

Relation ProductCategory {
  Product.id <-> Category.id
}

Le versionnage d'export (export ... version) assure la compatibilité des modules.

| Avantage | Description |

|-----------|-------------|

| Indépendance | Développement parallèle des modules |

| Versionnage | Git + versionnage sémantique pour les imports |

| Réutilisabilité | Modèles distribués via des bibliothèques |

Entités avancées : Commandes et Énumérations

Order.adb importe Core et Product, ajoutant des types de domaine :

// Order.adb
import "com.example.ecommerce.Core.adb" version 3.4.0
import "com.example.ecommerce.Product.adb" version 3.6.0

Enum OrderStatus {
  pending [note: "En attente de paiement"]
  paid
  shipped
  cancelled
}

Table Order extends Core.BusinessEntity {
  user_id uuid [ref: > Core.User.id]
  status OrderStatus [default: 'pending']
  total_amount decimal(12, 2) [not_null]
}

Enum s'intègre comme un type de champ. Suppression en cascade (on_delete: cascade) sur FK.

Points clés à retenir

• Déclaratif : Décrivez l'état souhaité ; les générateurs créent du DDL et des migrations.
• Modularité : Paquet + import/export pour un développement indépendant et CI/CD.
• Modèles : extends compose les champs d'audit, la suppression douce, la logique métier sans copier-coller.
• Validation : Vérifications au niveau du schéma, champs générés pour les calculs.
• Documentation : note, Group, Metadata génèrent des diagrammes et README.

Conseils pratiques de mise en œuvre

• Créez un Core.adb de base avec les modèles Identifiable, Auditable, SoftDeletable.
• Divisez le monolithe en Paquets par domaine : User, Product, Order.
• Configurez des hooks Git pour la validation du schéma avant les commits.
• Intégrez avec CI : Génération de DDL, tests de schéma, mises à jour de documentation.
• Pour les ORM : Scripts pour générer des entités à partir de .adb.

Metadata et Project définissent le contexte : database: "postgresql", version, auteur.

— Editorial Team