Architektura projektu v2 - kiedy co stosować?

Pisałem ostatnio, że chciałbym w pracy wprowadzić nieco inne standardy pisania kodu jak i podejście do architektury, czyli odejść od controller/service/repository
Architektura projektu - jak odejśc od klasycznego podziału

No i w międzyczasie zacząłem z kolegą pisać coś po godzinach, prosty projekt gdzie backend robi za nieco bardziej rozbudowanego CRUDa i udostępnia opcje logowania / rejestracji użytkowników. W planowanym MVP nie będzie więcej jak 5-6 usług.

No i zastanawiam się czy nie pójśc tutaj w odwrotną stronę jak w poprzednim wątku - może "klasyczne (controller/service/repository)" podejście tutaj jest wręcz wskazane? Przynajmniej na początek? Gdyby się okazało, że pomysł wypali i będziemy go dalej rozwijać, wtedy możliwe że dojdzie nieco więcej serwisów, wtedy może faktycznie inna architektura będzie bardziej odpowiednia, ale poki co czuje że jest to przerost formy nad treścią.

Druga sprawa, podział na różne warstwy danych - DTO, entity, encje biznesowe... Wszędzie powtarzają, że podział tego jest must have - czy faktycznie? Co jeżeli moja warstwa DTO to skopiowane klasy entity z dopiskiem Dto i usuniętą anodacją @Entity? Czy wtedy też warto się w to bawić czy znów wrócić do tematu gdy faktycznie będzie takie wymaganie?

Każda usługa może mieć inną architekturę - taką swobodę daje modularność.

Jest coś takiego jak metazasada KISS. Ja bym określił, które usługi będą się prawdopodobnie rozrastać i tam zastosował super fancy wzorce. Dla reszty, a prawdopodobnie będą to crudy - uprościłbym. To nie ma się podobać - to ma działać i być utrzymywalne.

Co do tych encji - przy architekturze portów&adapterów to norma, płacisz cenę za testowalność i rozszerzalność. Tutaj z pomocą może przyjść CQRS - jeśli potrzebujesz czytać jakieś dane celem ich prezentacji, możesz w read modelu pominąć całkowicie warstwę encji.

Zastanów się czy to co piszecie to projekt o skomplikowanej domenie biznesowej.

1. Jeżeli tak, to napiszcie sobie moduł z logiką systemu, ale tak aby świat zewnętrzny był tylko interfejsami. (do bazy danych, API, kolejek). Dobrze sobie go przetestujcie.
   Następnie w innym module zaimportujcie jak najprostsze narzędzia i biblioteki do baz danych, kolejek, API i posklejajcie to z waszym modułem domenowym.

2. Jeżeli nie, to piszcie CRUDa, najlepiej w PHP bo najszybciej.

Zakładam, że jednak nie piszecie projektu do szuflady i macie nadzieję, że kiedyś ten MVP urośnie i będzie wygrywał z innymi projektami sprytną domeną.
Piszcie kod w waszym języku, bez jakichś sztucznych ORMów, mapperów, aggregate rootów i innych narzędzi do których potrzeba 1000 stronicowych ksiąg i starodruków.

Jeszcze jeden hint ode mnie - jeśli robicie MVP jakiegoś produktu (w sumie nie wynika to z posta), to Waszym priorytetem jest zbadać zainteresowanie i zebrać feedback ASAP, zatem jakość kodu ma marginalne znaczenie.

@Charles_Ray:

Co do tych encji - przy architekturze portów&adapterów to norma, płacisz cenę za testowalność i rozszerzalność. Tutaj z pomocą może przyjść CQRS - jeśli potrzebujesz czytać jakieś dane celem ich prezentacji, możesz w read modelu pominąć całkowicie warstwę encji.

Jeśli nie korzystasz z JPA to często możesz obiekty domenowe wczytywac z bazy danych bez robienia klas pośredniczących

No więc chyba mam odpowiedź na swoje pytanie, obecnie chcemy zaimplementować proste MVP bez skomplikowanej logiki, więc pójdziemy najprostszym, najmniej czasochłonnym rozwiązaniem. Jeżeli produkt się przyjmie i backend się będzie rozrastał o nowe usługi, to pomyślimy o portach i adapterach bądź innej architekturze.