beberlei/litecqrs-php — pull request #22 by zerkalica (2012-11-11 13:05:04+00:00)
Title: Decouple AggregateResource

Why AggregateResource so strongly coupled with domain model ?

https://github.com/beberlei/litecqrs-php/blob/master/src/LiteCQRS/Plugin/CRUD/AggregateResource.php#L23

I think, inherit domain model from AggregateResource is not a good idea. Better to design without LiteCQRS dependency and incapsulate all in CRUDHelper. In this way we can keep old behaviour with setter/getter anemic domain, we can safely remove LiteCQRS library and refactor only small pieces of code (controller helper).

See LiteCQRS\Plugin\CRUD\CRUDCommandService. In my version, domain model is clear, but DomainAggregateResource decorates it.

About domain model accessible properties detection and update. There is a few ways to detect accessible properties in our domain. Map method in domain (getAccessibleProperties), setter method_exists, reflection property detection, annotations, config.

I realize first 3 methods in LiteCQRS\Plugin\CRUD\Updater\Filter components. UniversalFilter chains all of them and filters $event->data.

Filtered data from event can be writed through domain setters (LiteCQRS\Plugin\CRUD\Updater\SetterBasedUpdater), or injected directly to domain properties through reflection (LiteCQRS\Plugin\CRUD\Updater\ReflectionBasedUpdater). In reflection based updater we can unprotect domain property store value from event data and protect it back.

I incapsulate some components to traits, DomainAggregateResource - uses DomainAsProperty trait, and AggregateResource - uses DomainAsAggregate.

Some limitations (or not): our repository now is not AggregateRepositoryInterface, it stores any domain object.