Architectuur: BuildoraResource is een god object (355 regels, 25+ verantwoordelijkheden)

[ginkelsoft-development]

Probleem

src/Resources/BuildoraResource.php combineert te veel verantwoordelijkheden:

• Field-definitie (defineFields)
• Action-definitie (defineRowActions, defineBulkActions)
• Widget-definitie (defineWidgets)
• Panel-definitie (definePanels)
• Query bouw (query())
• Navigation config (showInNavigation, etc.)
• Search config (searchResultConfig)
• Permission resolution
• URL generation
• Model binding

Met 25+ public methods en ~355 regels is dit een textbook god object. SRP-violation: elke wijziging in één concern raakt de base class waar alle consumers van overerven.

Voorstel

Splits in collaborator objects die BuildoraResource delegeert:

• SearchConfig — searchResultConfig + columns
• NavigationConfig — show/hide, label, icon, group
• PermissionResolver — naming + ability mapping
• UrlGenerator — route names + paths
• ResourceQueryBuilder — query/scope hooks

BuildoraResource blijft de orchestrator die alleen field/action/panel-definities uitlevert.

Strategie

• Maak collaborators als value objects die in een trait of getter beschikbaar zijn
• Behoud backwards compatibility: oude method-namen blijven werken, delegeren naar de nieuwe objecten
• Marker oude methods als @deprecated met migratiepad

Acceptatiecriteria

• BuildoraResource < 150 regels, < 15 public methods
• Concerns gesplitst in 4-5 collaborator objects
• Bestaande consumer-code blijft werken (backwards compat)
• Test coverage voor elk collaborator object afzonderlijk