Dilema de abrigo para funcionalidades administrativas

[guiseek]

Atualmente o diretório agrupador account, que é escopo do domínio de contas de usuários, está abrigando as features shell (rota /conta), board (rota /conta/dashboard) e admin (rota /conta/administracao), conforme mostro na imagem abaixo.

A rota /conta/administracao permite contas com permissão director e manager alterar permissões de qualquer usuário, exceto o dele próprio, o mesmo vale para contas com permissão staff, leader e fellow, porém, eles podem atribuir permissões apenas com acesso menores que a própria permissão.

A rota /conta/dashboard no momento não possui nenhuma funcionalidade mas permitira obter relatórios úteis pra comunidade, apenas contas com permissão director e manager tem acesso.

Contas que possuem permissões speaker, leader e recruiter também requerem alguns acessos restritos, sendo para gerenciar apresentações, eventos e ofertas de trabalho, respectivamente.

Os documentos cadastrados obviamente estão referenciados pela conta de quem o cadastrou, e desta forma, trata-se de um dados relacionado a conta.

No momento quem abriga estas funcionalidades é a biblioteca account/feature-shell.

A discussão aqui é sobre a seguinte questão, o gerenciamento de apresentações (CRUD) deve se manter onde está (feature-shell do escopo account), ou em uma biblioteca feature-admin do escopo presentation, como é feito no gerenciamento de permissões de contas...

Temos o mesmo caso para gerenciamento de apresentações, gerenciamento de eventos e gerenciamento de ofertas de trabalho. Todas estão na mesma biblioteca, conforme citado acima.

Qual sua opinião sobre esta discussão?

[rhayonne]

Bom, primeiramente, seria legal ter a imagem do use-case para aprofundar mais a reflexão.
Através dele, creio que seria mais fácil tomar essa decisão, partindo disso, um use-case que imaginei a partir do que você descreveu @guiseek , acho mais pertinente as entidades serem separadas. Pensando na escalabilidade, você teria os módulos separados por sujeito ou por entidades, assim como os services e controls. Com isso, para a manutenção e no CD (desenvolvimento contínuo), você isola qualquer tipo de problema futuro em relação à certas especificações de cada entidade.
Outro ponto relevante é que, pelo que vi, esse projeto vai ficar enorme, com o tanto de features existentes, o quanto mais minucioso e setorização da arquitetura, melhor para a manutenção
Bom, se eu compreendi bem, é essa a minha colaboração.