Ciąg dalszy zagwozdek z Clean Architecture.
Powiedzmy, że korzystam z ASP.NET Core Identity i chcę mieć możliwość rejestracji użytkowników.
ASP.NET Core Identity wymaga swojego modelu użytkownika - a raczej tego żeby dziedziczył po IdentityUser
. Więc wiadomo, że to musi być zaimplementowane po stronie infrastruktury, a nie warstwy Core mojej aplikacji, bo w Core nie chcę zależności do innych frameworków.
Ale gdzie teraz obsłużyć rejestrację/logowanie/resetowanie hasła itp.?
Oczywiste wydawało mi się, że nie w Core, bo nie jest to część związana z domeną mojej aplikacji. Jakbym nie trzymał użytkowników po swojej stronie tylko korzystał z jakiegoś zewnętrznego Identity Providera to wtedy Core nic by o takich pojęciach jak logowanie czy rejestracja nie wiedział, więc i teraz raczej też nie powinien.
Ale jak nie chcę robić tego w Core to gdzie?
Niby mógłbym to zrobić w webie i wtedy z kontrolera zamiast wołać jakiś biznesowy UseCase bym po prostu wołał jakiś serwis odpowiedzialny za uwierzytelnianie/logowanie (który pod spodem korzystałby z klas dostarczonych przez ASP.NET Core Identity - SignInManager
i UserManager
), ale web nie powinien mieć bezpośrednio zależności do infrastruktury, wtedy w warstwie web definiować jakiś interfejs, który byłby zaimplementowany przez infrastrukturę (raczej przyzwyczajony jestem do tego że to Core definiuje interfejsy, które są implementowane przez infrastrukturę)? Druga kwestia jest taka, że według teorii web to tylko jeden punktów wejścia do apki i mógłby istnieć jakiś inny, no ale powiedzmy że to tylko teoria, bo jak mam apkę webową to raczej nie będzie miała innego wejścia od strony usera (np. jakiegoś CLI które często jest podawane w przykładach architektury heksagonalnej).
Pozwolę sobie zawołać @somekind @Aventus @ProgScibi