Domain patterns for enterprise integration — legacy modernization, strangler fig, anti-corruption layers, API gateways, canonical data models, event-carried state transfer, and failure modes. Use when designing or evaluating integration between existing enterprise systems, legacy modernization, or multi-system orchestration.
复制安装指令,让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "system-type-enterprise-integration" 技能: 1. 下载 https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-enterprise-integration/SKILL.md 2. 保存为 ~/.claude/skills/system-type-enterprise-integration/SKILL.md 3. 装好后重载技能,告诉我可以用了
Patterns, failure modes, and anti-patterns for connecting, modernizing, and orchestrating enterprise systems.
Enterprise integration is the art of making systems talk to each other when they were never designed to. Every pattern trades coupling for something — throughput, consistency, simplicity, or debuggability. The right choice depends on what you can afford to lose.
| Topology | Description | Coupling | Failure domain | Debuggability | When it works |
|---|---|---|---|---|---|
| Point-to-point | Direct connections between each pair of systems. N systems → N×(N-1)/2 connections. | Tightest — every system knows every other system's interface | Localized but unpredictable — one system's outage cascades differently depending on who depends on it | Easy when there are 3 systems, impossible at 15 | Small number of integrations (<5 systems), throwaway prototypes, or when two systems genuinely have a 1:1 relationship that won't grow |
| Hub-and-spoke (ESB) | Central bus mediates all communication. Systems only know the bus. | Moderate — systems decouple from each other but couple to the bus | Centralized — the bus is a SPOF for everything | Good — the bus logs everything (in theory) | When you need protocol translation, message transformation, and routing in one place. When governance requires a central integration team. When the number of systems is moderate (10–30) and the integration team has the capacity. |
| Event mesh / event backbone | Distributed event infrastructure (Kafka, Pulsar, etc.). Systems publish and subscribe to topics. No central broker logic. | Loosest — producers don't know consumers exist | Distributed — broker failure is partial, consumer failure is isolated | Harder — requires distributed tracing, topic monitoring, consumer lag tracking | When you have many (30+) systems, event-driven architectures, and teams that can own their own consumers. When you need to replay events for recovery or new consumers. |
Synchronous (request/reply). System A calls System B and waits for a response. The caller's latency includes the callee's latency. The caller's availability depends on the callee's availability.
When it's right:
When it creates coupling nightmares:
Asynchronous (fire-and-forget / event-driven). System A publishes a message or event and moves on. System B processes it whenever it can.
When it's right:
When it creates coupling nightmares:
…
Catalog of reusable architectural primitives — boundaries, contracts, state machines, queues, caches, consistency models, and more. For each: what it is, when it's right, when it's WRONG. Use when selecting patterns for a design or evaluating whether a pattern fits.
Domain-Driven Design as a lens for system architecture — bounded contexts, aggregates, ubiquitous language, context mapping, domain events, and strategic vs tactical patterns. Use when modeling complex business domains, defining service boundaries, or evaluating whether a system's structure reflects its domain.
The Unix/Linux design philosophy as a lens for system design — mechanism vs policy, composability, small tools, text streams, convention over configuration, and the principle of least surprise. Use when evaluating designs for composability, simplicity, or separation of concerns.
Object-oriented design principles as a lens for system architecture — SOLID, composition over inheritance, the actor model, design patterns (and when they're wrong), encapsulation, polymorphism, and responsibility-driven design. Use when evaluating code organization, module boundaries, or object/component relationships.
Domain patterns for Azure cloud architecture — compute selection, managed services, identity (Entra ID), networking, data platform, messaging, deployment, cost management, and operational patterns. Use when designing or evaluating a system deployed on Microsoft Azure.
Adversarial review of a system design from 6 critical perspectives -- SRE, security, staff engineer, finance, operator, and developer advocate. Produces a unified risk assessment. Use for INTERACTIVE on-demand reviews during a design conversation (/adversarial-review). For RECIPE-DRIVEN reviews (where prior step context is needed), use the systems-design-critic agent instead.