Software Architecture Patterns, Antipatterns, and Pitfalls

Chapter 11. Front Controller Pattern

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 18th chapter of the final book. Please note that the GitHub repo will be made active later on.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

The Front Controller pattern (alternatively known as “Front Orchestrator”) provides a way to add workflow state to choreographed workflows by adding it to the first-called service or event processor. This is a specialized version of the Externalized State Pattern (see Chapter 10).

The Front Controller metadata appears in Table 11-1.

Table 11-1. Metadata for the Front Controller pattern.

CATEGORY	METADATA
CONTEXT:	Event-Driven Architecture, Message-Based Architectures, Microservices, Workflow
IMPROVED:	Data Consistency, Data Integrity, Debuggability, Error Handling, Evolvability, Testability, Workflow
DEGRADED:	Availability, Domain Alignment, Fault Tolerance

How Do I Handle Mediation without an Orchestrator?

Many architects like the Choreography pattern for distributed architectures (see [Link to Come]) because it maps nicely to event-driven workflows. However, a common need architects have in those situations is to query the state of the workflow. ...