Czy aktorzy Akka mogą zastąpić warstwę usługi?

Question

To jest bardziej pytanie dotyczące projektowania i najlepszych praktyk. Przekształcam aplikację, aby korzystać z Aktorów i kontraktów terminowych. Obecnie są to warstwy (zanim Akka znajdzie się w miksie).

Play Controller -> Service layer -> (Slick) DAOs 

Teraz chcą mieć coś podobnego

Play Controller -> Actors ->Services (Now they'll return Futures) ->DAO 

Czyniąc tak jestem od stwierdzenia, że ​​oryginalna warstwa Usługa miał wszystkie metody z wymaganej logiki biznesowej, aktorów warstwa patrzy jak mediatora. Zastanawiasz się, czy jest w porządku (z punktu widzenia projektu), aby pozbyć się warstwy usługi teraz, gdy wszystko będzie przez aktorów?

Play controller->Actors (with business methods) -> business methods calling into DAO (which Service methods were doing before) 

Lub kontynuować z istniejącą warstwą Service i używać tych metod tylko od Akka Actors? Ryzyko związane z utrzymaniem warstwy usługi w obecnej postaci, jest takie, że wszystkie metody Usług pozostają publiczne i można je wywoływać z dowolnego miejsca (łamanie schematu, jeśli ktoś nazwał metodę usługi bezpośrednio w kontrolerze (przez przekazanie aktorów) lub coś takiego).

Answer 1

Istnieją 2 podejścia do aktora na bazie projektu systemu:

• aktorzy są tylko abstrakcją wielowątkowość, np TaskExecutor s
• Podmioty są podstawą modelowania biznesowego, np. GhostActor w grze Pac-Man.

Musisz zadać sobie pytanie, który z nich chcesz zastosować po refaktoryzacji. I dlaczego.

Pierwsza opcja, o której wspomniałeś (Aktorzy rozmawiają z Usługami za pośrednictwem kontraktów terminowych) to wielowątkowość. Chcesz to zrobić, kiedy właśnie trafiłeś w wąskie gardło wydajności. Prawdopodobnie aktorzy mogą pomóc, ale istnieje wiele innych narzędzi, które mogą to zrobić.

Druga opcja, o której wspomniałeś (Aktorzy zastępują Usługi) używa aktorów do modelowania w domenie biznesowej. Jest bardzo potężny. Umieszczasz swoją logikę w aktach, które składają się z mniejszych aktorów, które składają się z mniejszych aktorów i tak dalej. Każda z nich reprezentuje niewielką część domeny biznesowej. Im mniejszy aktor, tym lepiej. Istnieje wiele korzyści z zastosowania tego podejścia:

• Każdy z tych podmiotów może wewnętrznie stosować inną strategię pozyskiwania i przechowywania informacji. Niektóre z nich mogą korzystać z usługi HTTP za pośrednictwem Futures, niektóre z nich mogą wykorzystywać komunikację aktorską, niektóre z nich mogą pochodzić z wydarzeń.
• Masz deklaratywną i zrozumiałą dla człowieka abstrakcję, której możesz użyć w całym systemie: Aktor. Po prostu musisz zmienić swój mózg od myślenia o przeszkodach technicznych w myśleniu o przeszkodach biznesowych.
• Gdy stosujesz się do prostych reguł technicznych, masz wbudowaną skalowalność systemu, nie myśląc o tym za dużo. Te zasady stają się po pewnym czasie drugą naturą.

Oczywiście, istnieją również pewne minusy:

• Istnieją dziedziny biznesu, które nie mogą być łatwo modelowane z aktorami.
• System jest całkowicie zależny od jednego zestawu narzędzi.

Mam nadzieję, że to może ci jakoś pomóc. Jeśli chcesz się czegoś dowiedzieć, po prostu to wykrzycz. Dzięki!