Observer Pattern to Event-Driven Architecture in Dart
Oluwaseyi Fatunmole's comprehensive handbook traces a single architectural journey: from the Gang of Four Observer pattern through Event-Driven Architecture and Domain-Driven Design, landing on a production-grade Dart/Flutter architecture with Riverpod. The through-line is decoupling — separating what happened from what should happen because of it — and the piece earns its "handbook" label by building every concept in code, not just describing it.
Key Quotes
"The login logic does one thing: it performs the login and announces the result."
This is the entire argument in nine words. Everything downstream — token persistence, cache warming, navigation, analytics — becomes a subscriber to the announcement, not a line in the login function. The pattern doesn't reduce the work; it redistributes it into independently testable, independently changeable units.
"Events are facts, not commands."
The sharpest conceptual line in the piece. A command says "do this" and expects a response; an event says "this happened." The distinction sounds academic until you hit the practical consequence: events-as-facts make systems auditable and replayable in ways command-driven architectures structurally cannot be. This is the bridge from Observer to Event-Driven Architecture, and Fatunmole draws it clearly.
"The critical rule: the domain layer is pure Dart. No Flutter imports. No Riverpod imports. No HTTP imports."
The DDD section's anchor. The domain layer owns the business logic and depends on nothing. This isn't just Clean Architecture dogma — it's a testability argument. When domain events, handlers, and use cases are pure Dart, they're testable without a Flutter runtime. The author makes this concrete with folder structure and dependency rules, not just principles.
"The use case owns domain consequences. The notifier owns UI state. Widgets own nothing."
The final architecture's division of labor, stated with uncommon clarity. The notifier becomes thin enough to fit on a screen — it calls the use case and maps the result to AsyncData/AsyncLoading/AsyncError. Token saving, navigation, and analytics are already handled by event handlers that fired before the notifier even saw the result. Widgets become pure rendering functions.
"Without this, one failing observer would stop the entire notification chain."
On the per-observer try/catch. This is the kind of production detail that separates pattern tutorials from production guides. Combined with snapshot iteration (List.of(_observers)) to prevent concurrent modification during notification loops, the author surfaces two failure modes most Observer introductions never mention.
Key Themes
Critical Analysis
What makes this piece valuable: It's unusually complete for a freeCodeCamp article — it doesn't stop at the pattern definition. It walks through concrete Dart implementation, production concerns (snapshot iteration, per-observer error isolation), a generic reusable EventBus, the connection to DDD domain events, and a full Riverpod integration. The testing section is genuinely useful: each layer (use case, handler, notifier) gets its own test strategy with clear boundaries about what does and doesn't need mocking. Most tutorials skip testing entirely.
The hidden argument: Fatunmole is making a case that Flutter developers should reach for explicit Observer/EventBus patterns rather than letting Riverpod's reactivity absorb everything. The two pain points he names — "fat ref.listen in widgets" and "fat notifiers" — are real Flutter pathologies. His solution (events fire independently of widget lifecycle) means the architecture works identically whether login is triggered from a widget, a biometric prompt, a deep link, or a background service. This is a stronger argument than "decoupling is good" — it's "decoupling makes your code work in contexts you haven't built yet."
What's undersold: The article presents the Event-Driven Architecture section as a natural extension of Observer, but there's a genuine conceptual leap between "notify observers when state changes" and "events are immutable facts with timestamps and IDs." The GoF Observer is about state-change notification; EDA is about event sourcing and replay. The article collapses the distance productively for beginners, but an experienced reader will notice the hand-wave.
The generic EventBus is the most reusable contribution. Rather than building a separate Subject/Observer hierarchy for every feature (login, payment, order), the EventBus<T> pattern makes the Observer infrastructure a one-time investment. This is the moment the article shifts from "here's a pattern" to "here's infrastructure you can actually ship."
Where it connects to the wiki's themes: This piece fills a gap between Event-Driven vs Polling Architectures (which covers the ingestion side of EDA for agents) and Signals — The Push-Pull Algorithm (which covers fine-grained reactive propagation). The Observer/EventBus sits in the middle: coarse-grained domain events that fan out to independent handlers. The push-pull distinction Brauner explores — push invalidation, pull re-evaluation — is the same mechanism that makes Fatunmole's architecture testable: handlers only run when an event fires, and each handler only does its one thing.
The DDD connection is right but shallow. Mentioning aggregates as "the natural source of domain events" is correct but the article doesn't show a worked aggregate example. The Domain Storytelling method would be the natural complement — use domain storytelling to discover which events actually matter in the business domain before designing the event bus. Similarly, Why Build vs Buy is the Wrong Question applies Evans's subdomain taxonomy to build decisions; Fatunmole's architecture implicitly assumes you've already decided the domain is complex enough to warrant DDD.
What I'd add: The pattern excels at adding side effects (one new handler, one registration line) but the article doesn't address removing or reordering them. In production, you eventually need to deprecate handlers or guarantee execution order for regulatory reasons. The Map<Type, List<EventHandler>> design offers no ordering guarantees beyond insertion order — which works until it doesn't. For systems where handler ordering matters, you need something closer to Process Flow's chain-of-stages model or a proper workflow engine.
Bottom line: This is the article to hand a Flutter developer who's outgrown putting everything in the notifier. The Dart code is concrete, the progression from Observer → EventBus → Domain Events → Riverpod is well-paced, and the testing strategy alone justifies reading it. The DDD and Clean Architecture sections are more gesture than substance, but as a map of how these ideas connect, it's unusually coherent.
Sources: raw/observer-design-pattern-handbook-dart Last updated: 2026-07-18