Odpowiedzi:
Linie mogą być trochę rozmyte, ale widzę to w ten sposób:
Klasa / interfejs usługi umożliwia klientowi interakcję z niektórymi funkcjami aplikacji. Jest to zazwyczaj publiczne, o pewnym znaczeniu biznesowym. Na przykład, TicketingServiceinterfejs może pozwolić ci buyTicket, sellTicketi tak dalej.
Klasa pomocnicza jest zwykle ukryta przed klientem i jest używana wewnętrznie w celu zapewnienia pracy nad płytą kotłową, która nie ma znaczenia dla domeny biznesowej. Załóżmy na przykład, że chcesz przekonwertować datę na znacznik czasu, aby zapisać ją w określonym magazynie danych. Możesz mieć klasę narzędziową wywoływaną DateConvertorza pomocą convertDateToTimestampmetody, która wykonuje to przetwarzanie.
Usługi nie są po prostu ściśle powiązane z DAO, to szerszy termin / wzorzec użytkowania niż trwałość
Klasy pomocników nie naruszają SRP, jeśli są kodowane zgodnie z tą zasadą. Oznacza to, że każda metoda powinna zrobić jedną rzecz i jedną rzecz dobrze, klasa powinna wykonać jeden rodzaj pomocy narzędzia (np. Konwersję daty) i zrobić to dobrze.
Nie jest to definicja naukowa, ale ogólnie uważam, że klasa usług ma pewien kontekst w aplikacji, podczas gdy pomocnicy są bardziej ogólni i nie dbają o to, jaką aplikację pomagają.
Dla mnie wybieram definicję Erica Evansa,service która jest mniej więcej taka:
Zasadniczo w dobrze zaprojektowanym systemie większość klas (w modelu domenowym) ma dość wyraźną odpowiedzialność lub funkcję, ponieważ zajmuje się określoną jednostką lub zestawem jednostek w modelu.
to znaczy
Jeśli masz funkcjonalność, która nie należy do żadnego konkretnego bytu, może być trudno znaleźć odpowiednie miejsce do siedzenia. Tj. Coś, co obejmuje proces, który obejmuje zarówno AccountORAZ Customer.
I tu właśnie servicepojawia się miejsce. Tu umieszczasz kod, który znajduje się w modelu domeny, ale naturalnie nie należy do żadnej jednostki / komponentu.
Myślę o helperczymś w rodzaju klasy strategicznej. Dla mnie jest to miejsce, w którym należy umieścić kod, który musi być ponownie użyty przez różne klasy, ale może nie być całkiem dobry jako abstrakcyjne metody w hierarchii klas, które go używają. Osobiście uważam, że termin helperjest nieco niejasny i tak naprawdę nie mam go w moim modelu. Chociaż istnieją w bibliotekach, których używam.
Klasa usługi: zawiera logikę biznesową.
Klasa pomocnicza: ta klasa jest jednym rodzajem elementu wielokrotnego użytku.
Pomieszałeś dwa niezwiązane ze sobą podmioty. Usługi i klasy pomocnicze nie są połączone. Zwłaszcza termin „klasa usług” wprowadza w błąd - myślę, że masz na myśli „usługę”, która ma wyższy poziom abstrakcji niż klasy. Usługa charakteryzuje się poprzez
„mechanizm umożliwiający dostęp do jednej lub więcej możliwości, przy czym dostęp jest zapewniany przy użyciu określonego interfejsu i jest realizowany zgodnie z ograniczeniami i zasadami określonymi w opisie usługi.”
Ta definicja nieznacznie się zmienia w zależności od kontekstu. Krytycznym punktem jest jednak to, że termin „usługa” znajduje się na poziomie abstrakcyjnym , na poziomie architektury i wiedzy w dziedzinie . „Klasa pomocnicza” to wzorzec projektowy (mimo że jest anty-wzorzec, ponieważ mają tendencję do ewolucji do klas obiektów blob lub boskich), odnoszący się do klasy, która zawiera operacje ogólne (zauważ, że jest ona na niższym poziomie abstrakcji i jest połączona do wiedzy na temat aplikacji / rozwiązania ). Zdaję sobie sprawę z faktu, że prawie nie istnieje oprogramowanie niezawierające żadnej klasy pomocniczej, ale nadal jest to zła praktyka.
Jedną z rzeczy, na którą należy uważać, jest wiele definicji „usługi” w DDD:
Usługa aplikacji: znajdują się w warstwie aplikacji i komunikują się z domeną i warstwą danych, są interfejsem, poprzez który systemy zewnętrzne / interfejs użytkownika wchodzą w interakcje z systemem DDD.
Usługa domenowa: może być używana przez domenę lub warstwę aplikacji i zawiera logikę biznesową, która nie pasuje do jednego konkretnego podmiotu.
Usługa infrastruktury: są one używane przez domenę do komunikacji z zasobami zewnętrznymi.
Klasy pomocników zwykle zawierają fragmenty kodu lub algorytmy, które byłyby ponownie wykorzystywane przez wiele jednostek, więc nie można tak naprawdę wchodzić w jednostki bez naruszenia zasady DRY. Prawdopodobnie są one najbliższe usługom domenowym, ponieważ w pewnym sensie spełniają ten sam cel (eksternalizacja logiki biznesowej od podmiotów), ale robią to z różnych powodów.