Patterns: composition · 3 MIN READ
Facade: one useful entry point over a subsystem
Simplify orchestration without pretending several effects are atomic.
Simplify orchestration without pretending several effects are atomic. A facade offers a convenient operation over several lower-level components. Trace the worked Go example, then compare the benefit with the cost before applying this design to your own project.
Structural pattern · A MAP OF THE IDEA
- Client requests one workflow
- Facade coordinates subsystem steps
- Subsystems retain their own responsibilities
Useful when
- Clients repeat the same orchestration
- A subsystem API exposes too much detail
Watch out
- One convenience method is not a transaction
- Broad facades can become god objects
Implementation & operation cost: Low to medium
Fit depends on the task
Editorial suitability, not benchmarks or a universal ranking. Styles describe different axes and can be combined.
The design decision
A facade offers a convenient operation over several lower-level components. It can coordinate validation, inventory and notification, but convenience does not provide a transaction. The facade should report which promises it can actually make if a later step fails.
A complete Go example
Read this program from the entry point and follow the calls shown in the diagram. The output is included at the end so you can check the behavior without a compiler.
package main
import (
"errors"
"fmt"
)
type Checkout struct {
Stock int
Sent int
}
func (c *Checkout) Buy(n int) error {
if n <= 0 || n > c.Stock {
return errors.New("invalid quantity")
}
c.Stock -= n
c.Sent++
return nil
}
func main() {
c := &Checkout{Stock: 4}
fmt.Println(c.Buy(2))
fmt.Println(c.Stock, c.Sent)
}
// Output:
// <nil>
// 2 1
Buy hides two local state changes behind one operation and validates before mutating. This single-owner in-memory example cannot fail after validation. Replacing Sent with an email or payment call introduces a new failure boundary that must be designed explicitly.
Tradeoffs and the simpler alternative
A facade can become a god object if it owns every policy. Keep it focused on one client workflow, delegate domain rules, and use transactions or durable workflows where partial effects matter. A simple helper function can be the whole facade in Go.
TAKE THIS WITH YOU
Provides a focused entry point to a subsystem. A facade can become a god object if it owns every policy. Keep it focused on one client workflow, delegate domain rules, and use transactions or durable workflows where partial effects matter. A simple helper function can be the whole facade in Go.
Check your understanding
Which statement best describes Facade: one useful entry point over a subsystem?
Go to the source
Progress stays in this browser. No account needed.