Studiuję czystość, w wyniku czego dość radykalnie zastanawiam się nad tym, jak projektuję i piszę oprogramowanie.
Wciąż mam problem z regułami biznesowymi, takimi jak: „przy zapisywaniu aktualizacji jakiegoś elementu, najpierw załaduj całą listę elementów, które mam uprawnienia do przeglądania / edycji itp., Potwierdź, że ten element jest na liście, oraz że kategoria pozycji nie jest obecnie zablokowana ((i inne reguły itp.) „), ponieważ jest to (złożona, ale nietypowa) reguła biznesowa, dlatego należy ją obsługiwać w domenie aplikacji, a nie wprowadzać logikę biznesową do warstwa db / trwałość.
Wydaje mi się jednak, że aby skutecznie sprawdzić te warunki, najlepiej będzie najlepiej obsłużyć ładnie spreparowane zapytanie db, zamiast ładować wszystkie dane do domeny aplikacji ...
Bez przedwczesnej optymalizacji, jakie jest zalecane podejście lub niektóre artykuły wuja Boba dotyczące tego pytania? A może powie „waliduj w domenie, dopóki nie stanie się to problemem”?
Naprawdę staram się znaleźć jakieś dobre przykłady / próbki dla czegoś innego niż najbardziej podstawowe przypadki użycia.
Aktualizacja:
Cześć wszystkim, dziękuję za odpowiedzi. Powinienem być bardziej przejrzysty, piszę oprogramowanie (głównie aplikacje internetowe) od dłuższego czasu, i zdecydowanie już doświadczyłem i zgadzam się ze wszystkimi tematami, które wspólnie opisujesz (weryfikacja przez backend, nie ufaj danym klienta, ogólnie mówiąc ścigaj się z surową wydajnością tylko wtedy, gdy jest to wymagane, ale potwierdź zalety narzędzi db, jeśli są dostępne, itp. itp.) i przeszedłem cykl uczenia się programisty od „zrzuć to wszystko”, aby „zbudować gigantyczny kontroler tłuszczu z aplikacjami N-poziomów” , a teraz naprawdę lubię i analizuję styl czystej / pojedynczej odpowiedzialności itp., zasadniczo w wyniku kilku projektów, które niedawno przekształciły się w dość niezgrabne i szeroko rozpowszechnione reguły biznesowe, gdy projekty ewoluowały i pojawiły się dalsze wymagania klientów.
W szczególności patrzę na czystą architekturę stylu w kontekście budowania apletów REST do obsługi klienta, a także do funkcji użytku wewnętrznego, w których wiele reguł biznesowych może być znacznie bardziej złożonych niż w zasadzie każdy przykład widziany w sieci (nawet przez samych architektów Clean / Hex).
Wydaje mi się, że naprawdę pytałem (i nie powiedziałem jasno) o to, w jaki sposób API Clean i REST będą siedzieć razem, gdzie większość rzeczy MVC, które widzisz w tych dniach, ma sprawdzanie poprawności żądań (np. Biblioteka FluentValidation w .NET), ale gdzie wiele z moje zasady „sprawdzania poprawności” to nie tyle ”to ciąg mniejszy niż 50 znaków„ ale więcej ”ten użytkownik wywołujący tę skrzynkę użytkownika / interactor może wykonać tę operację na tym zbiorze danych, biorąc pod uwagę, że jakiś powiązany obiekt jest obecnie zablokowany przez Zespół X do późniejszego miesiąca itp. itd. ”... tego rodzaju głęboko zaangażowane walidacje, w których stosuje się DUŻO obiektów domeny biznesowej i reguł domeny.
Czy powinienem przekształcić te reguły w określony rodzaj typu obiektu walidatora, który będzie towarzyszył każdemu interakcyjnemu przypadkowi użycia (zainspirowany projektem FluentValidator, ale z większą logiką biznesową i dostępem do danych), czy powinienem traktować walidację trochę jak bramę? umieść te walidacje w bramie (co moim zdaniem jest złe) itp. itp.
Dla porównania, mam zamiar się kilka artykułów takich jak ten , ale nie omawia Mattia walidacja dużo.
Wydaje mi się jednak, że krótka odpowiedź na moje pytanie przypomina odpowiedź, którą zaakceptowałem: „To nigdy nie jest łatwe i zależy”.