This is a transcript of a discussion I had with Guillaume Sauthier and shared with the other teams members. Everything is in here, even the configuration as an acceptance criteria
AmService becomes fatter and fatter with all these services, and its companion builder suffer the same effect. And we know that soon we will refactor the PEF and add a kind of PolicyService to AmService.
AmService should factorize the credentials, the CHF Handler that provides automatic authentication, the notification service. Nothing more.
The SessionService, UserProfile and soon PolicyService are services that rely on an AmService but that may not be the role of AmService to hold them. The motivation for that is really the configuration of that services. Recently, I moved the profileAttributes to AmService configuration: I was obliged to do that as we implicitly agreed that such services should be held and instantiated by AmService.
But yesterday we mentioned about another way to do it: such services could be instantiated through Heaplet and thus reside in the Heap where the other filters could look them up. By doing so, the configuration of the services are really part of the declaration of these services; and it would be possible to share the service instances among different filters, or to have different instances of each service configured differently if needed.
That would give a setup like the following for the UserProfileFilter:
I really like this kind of setup, definitely, split-up the responsibility to where they are used.
The inline declaration of the UserProfileService-2 is quite natural too.
The same exercice could be done for the filters that depends on the SessionService to show the benefits.