>> BFF<Orchestrator>

In my current categories BFF is not a kind of Orchestrator because the orchestration layer of BFF has multiple components (services) by definition. Also, that layer of BFF may instead contain proxies (e.g. gateways that translate from external protocols that vary by client to an internal protocol which is used by the underlying system of services).

Such a classification may not be fair to the reality, but nobody has made a practical categorization for patterns based on their function (4 groups of hundreds of patterns don't help much). Thus I turned to structural diagrams as the main means of classification. And that approach, though usually quite intuitive, may assign closely related patterns to separate bins, or may be ambiguous.

For example, BFF gets a dedicated entry though it means multiple orchestrators (but I actually had a lot to write about when and why use multiple orchestrators!). Polyglot Persistence is just multiple (shared) databases, but it also covers many peculiar CQRS-related cases, which cannot appear with a single database. Thus, in my opinion, it pays back to discuss them in separate classes.

The child(parent(grandparent)) notation is used for the patterns lists of evolutions. For example, the "Move all the data to a shared repository" evolution of Shards lists the resulting patterns as: Pool (Shards), Shared Database (Shared Repository), Load Balancer (Proxy), Layers. You can find it here https://itnext.io/shards-2637f1ae7771