The dendritic pattern makes every file a flake-parts module, so one file can contribute to NixOS, Home Manager, and darwin at once. Its advocates describe this with aspect-oriented vocabulary: cross-cutting concerns, weaving, aspects. The vibe fits; the structure does not. In classical AOP (Kiczales et al., 1997) aspects overlay a primary class hierarchy that exists independently, and a weaver injects behavior at join points the base code never declared. Dendritic has no base hierarchy to overlay. Its modules are the primary decomposition, and nothing is injected anywhere: the module system merges declared contributions to a fixed point.
That is feature-oriented programming. The Software Product Lines literature has spent twenty years on deriving variants from a shared base by composing optional features at declared variability points, which is exactly what imports plus mkIf do. Ferreira et al. (2014) find FOP “requires few changes in source code… better support than other techniques for non-intrusive insertions,” and that is a precise description of what mkDefault and mkForce buy.
The distinction is not pedantry. It changes which literature answers your next question: AOP will not tell you how to test a variability point, and SPL/FOP will. When defending a Nix architecture in writing, cite Dolstra (2007) for the paradigm and Tarr et al. (1999) for the multi-axis decomposition, not Kiczales. See Academic Foundations of Nix Configuration Patterns.