Architecte Logiciel : systèmes scalables et robustes

Le rôle d'architecte logiciel

L'Architecte Logiciel est le profil qui prend du recul sur le code pour concevoir les systèmes dans leur globalité. Son objectif : garantir que les choix techniques d'aujourd'hui ne deviennent pas les dettes insurmontables de demain.

Il intervient en amont du développement pour définir les grandes lignes du système : découpage en composants, choix des patterns, sélection des technologies, définition des interfaces entre modules.

Ses responsabilités principales :

• Définir et documenter l'architecture technique des applications
• Garantir la scalabilité, la maintenabilité et la résilience du système
• Choisir les patterns architecturaux adaptés aux besoins métier
• Guider les équipes de développement dans les choix techniques
• Conduire les revues d'architecture (Architecture Decision Records)
• Gérer la dette technique et planifier les migrations
• Faire le pont entre les contraintes business et les réalités techniques

Patterns architecturaux clés

Clean Architecture

Popularisée par Robert C. Martin (Uncle Bob), la Clean Architecture organise le code en couches concentriques où les dépendances ne pointent que vers l'intérieur. Le domaine métier est isolé de toute dépendance externe.

// Clean Architecture - structure type en TypeScript

// Couche Domain (au centre, aucune dépendance externe)
// entities/User.ts
export class User {
  constructor(
    public readonly id: string,
    public readonly email: string,
    public readonly name: string
  ) {}

  isValid(): boolean {
    return this.email.includes('@') && this.name.length > 0;
  }
}

// use-cases/CreateUser.ts
export class CreateUserUseCase {
  constructor(private readonly userRepo: UserRepository) {}

  async execute(dto: CreateUserDTO): Promise<User> {
    const user = new User(generateId(), dto.email, dto.name);
    if (!user.isValid()) throw new Error('Données utilisateur invalides');
    return this.userRepo.save(user);
  }
}

// Couche Infrastructure (dépend du domaine, jamais l'inverse)
// repositories/PostgresUserRepository.ts
export class PostgresUserRepository implements UserRepository {
  async save(user: User): Promise<User> {
    await db.query('INSERT INTO users VALUES ($1, $2, $3)',
      [user.id, user.email, user.name]);
    return user;
  }
}

Domain-Driven Design (DDD)

Le DDD place le modèle métier au coeur de l'architecture. Les concepts clés sont les Bounded Contexts, les Aggregates, les Value Objects et les Domain Events.

// DDD - Value Object immuable
export class Money {
  constructor(
    public readonly amount: number,
    public readonly currency: 'EUR' | 'USD'
  ) {
    if (amount < 0) throw new Error('Montant négatif invalide');
    Object.freeze(this);
  }

  add(other: Money): Money {
    if (this.currency !== other.currency)
      throw new Error('Devises incompatibles');
    return new Money(this.amount + other.amount, this.currency);
  }

  equals(other: Money): boolean {
    return this.amount === other.amount && this.currency === other.currency;
  }
}

// Aggregate root
export class Order {
  private items: OrderItem[] = [];
  private domainEvents: DomainEvent[] = [];

  addItem(product: Product, qty: number): void {
    const item = new OrderItem(product, qty);
    this.items.push(item);
    this.domainEvents.push(new ItemAddedEvent(this.id, product.id));
  }

  get total(): Money {
    return this.items.reduce(
      (sum, item) => sum.add(item.subtotal),
      new Money(0, 'EUR')
    );
  }
}

CQRS — Command Query Responsibility Segregation

CQRS sépare les opérations de lecture (Query) des opérations d'écriture (Command). Chaque côté peut être optimisé indépendamment, ce qui est particulièrement puissant dans des systèmes à fort trafic.

// CQRS - séparation Command / Query

// Command : modifie l'état
interface CreateOrderCommand {
  customerId: string;
  items: { productId: string; quantity: number }[];
}

class CreateOrderHandler {
  async handle(cmd: CreateOrderCommand): Promise<string> {
    const order = Order.create(cmd.customerId, cmd.items);
    await this.orderRepo.save(order);
    await this.eventBus.publish(new OrderCreatedEvent(order.id));
    return order.id;
  }
}

// Query : lecture optimisée (peut utiliser une vue dénormalisée)
interface GetOrderSummaryQuery { orderId: string; }

class GetOrderSummaryHandler {
  async handle(q: GetOrderSummaryQuery): Promise<OrderSummaryDTO> {
    // Lecture depuis une projection optimisée pour la lecture
    return this.readModel.findOrderSummary(q.orderId);
  }
}

Microservices vs Monolithe

L'un des choix architecturaux les plus importants est la granularité du découpage. Il n'existe pas de réponse universelle — le bon choix dépend du contexte.

Quand choisir le monolithe :

• Équipe petite (moins de 10 développeurs)
• Domaine métier pas encore stabilisé
• MVP / produit en phase de découverte
• Coût opérationnel à minimiser

Quand migrer vers les microservices :

• Équipes multiples sur le même code (couplage organisationnel)
• Besoins de scalabilité indépendants par domaine
• Cycles de déploiement indépendants requis
• Domaine métier bien maîtrisé avec des Bounded Contexts clairs

Outils et diagrammes

L'architecte utilise des notations standardisées pour communiquer ses décisions :

• C4 Model — 4 niveaux de diagrammes : Context, Container, Component, Code
• UML — diagrammes de classes, séquence, déploiement
• Arc42 — template de documentation d'architecture
• ADR (Architecture Decision Records) — journalisation des décisions techniques

Outils de dessin :

• draw.io / diagrams.net — diagrammes gratuits et collaboratifs
• Miro / Mural — collaboration en temps réel sur des boards
• PlantUML — diagrammes as code (versionnable dans Git)
• Lucidchart — outil professionnel de diagrammes
• Structurizr — outil C4 Model dédié

Compétences, évolution et salaire

Compétences non-techniques essentielles :

• Communication : traduire les contraintes techniques en langage business
• Facilitation : animer des ateliers d'architecture (Event Storming, Impact Mapping)
• Influence sans autorité : convaincre les équipes d'adopter les bonnes pratiques
• Vision long terme : anticiper les évolutions technologiques et business