Ports, Adapters, and Other Ways to Stop Breaking Your Business Logic
summary
Criteo applies Hexagonal Architecture to keep business logic independent from REST, Kafka, ORMs and stored procedures, claiming fewer changes to domain code as APIs evolve; the org runs 800 developers, 160 teams, ~1,000 production services and ships via trunk-based development and feature flags. Examples use C#, Entity Framework, Kafka, REST with generated OpenAPI clients, anti-corruption layers and modular-monolith→microservice splits. Architecture rules are enforced with ArchUnit.NET, CI builds catch client breakages, and the pattern proves pragmatic rather than dogmatic in reducing coupling and easing refactors.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:05Criteo’s architecture
- 8:25Business logic pollution
- 11:15Anti-corruption layers
- 13:00Layered architecture limits
- 17:33Dependency inversion and ports
- 20:26Hexagonal architecture
- 22:12Modular monoliths
- 26:46Enforcing architecture
- 31:02ORM strategies
- 33:29Query vs command
- 35:59Key takeaways
- 36:40Q&A
related talks
50mA Practical Use Case of Software Architecture Evolution
45mThe Hexagonal - Ports & Adapters Architecture
50mEvolutionary Distillation of Architecture
51mCompetitive retail architecture with microservices
29mCOTS in a Reactive Architecture
40mDDD, CQRS, Hexagonal, Onion,... Putting it together
52mWhy not all hexagons have eight sides
56mArchitecting Cloud Native Microservices