Projektowanie aplikacji może być czasami trudne, szczególnie jeśli projektujemy kilka domen i muszą one ze sobą współdziałać. Aby zapobiec tym komplikacjom, możemy wykorzystać niektóre koncepcje i implementacje w naszej aplikacji.
W tym wpisie podzielę się kilkoma przemyśleniami na temat Wydarzeń Domenowych i Wydarzeń Integracyjnych, kilkoma praktycznymi przykładami i odniosę je do projektu aplikacji.
Co to jest ?
Według Martina Fowlera zdarzenie domenowe "przechwytuje pamięć o czymś ciekawym, co wpływa na domenę".
Co to jest w prawdziwym świecie?
Powiedzmy, że John i Mark pracują razem w dziale sprzedaży firmy i robią trochę papierkowej roboty. Po pierwsze, John tworzy odręczny budżet, biorąc pod uwagę prośbę klienta i obliczając niektóre podatki. Następnie, Mark zabiera ten papier i przesyła go faksem do klienta (czy nadal istnieje?).
Na podstawie tej historii możemy zauważyć, że praca Marka jest powiązana z pracą Johna, ale niekoniecznie są one powiązane. Na przykład, Mark może czekać na wszystkie budżety w ciągu jednego dnia, a następnie wysyłać je do klientów.
Innymi słowy, tworzenie budżetu jest częścią tej samej domeny powiadamiania klienta o tym budżecie, ale te działania nie są częścią tego samego procesu.
Na koniec mamy stworzoną "pamięć" budżetu, która wpływa na "domenę sprzedaży" poprzez wykorzystanie tej pamięci do wysłania budżetu do klienta.
A co z projektem aplikacji ?
Muszą one być zaimplementowane w ramach konkretnej domeny lub tej samej aplikacji logicznej. Jej granice muszą być bardzo dobrze wytyczone.
Gdybyśmy zaprojektowali aplikację do naszej historii, mielibyśmy następujący scenariusz:
Jedna aplikacja, która przyjmuje prośbę klienta, oblicza podatki, rejestruje budżet, a następnie publikuje informację, że budżet został stworzony.
Drugi proces subskrybowałby zdarzenia domenowe, rozpocząłby odsłuchiwanie zdarzenia "utworzonego budżetu", a następnie wysłałby e-mail do klienta, kiedy to nastąpi.
Jakie są korzyści z tego wynikające ?
Mogę wymienić kilka korzyści:
Co to jest ?
Zaangażowane zdarzenie, które miało miejsce w przeszłości w ograniczonym kontekście, który może być interesujący dla innych domen, aplikacji lub usług osób trzecich.
Co to jest w prawdziwym świecie ?
Teraz powiedzmy, że kiedy John kończy pracę, idzie do działu marketingu firmy i dostarcza kopię budżetu. Z tą kopią w rękach, Julia wybiera kilku dobrych klientów, aby przy następnych zakupach dostarczyć specjalny kupon rabatowy.
Dodając tę część historii, możemy zauważyć, że Julia jest częścią innej domeny o nazwie Marketing.
Należy również pamiętać, że to samo zdarzenie miało miejsce w przeszłości (budżet utworzony), ale teraz w innej domenie. Oznacza to, że nie musi wiedzieć, jak budżet został utworzony, obliczony, a nawet wysłany do klienta. Musi tylko wykonać swoją pracę marketingową.
A co z projektem aplikacji?
Ten scenariusz nie skupia się na konkretnym projekcie aplikacji, ale na całym systemie. Kiedy mamy do czynienia z systemami rozproszonymi, możemy myśleć o posiadaniu dwóch oddzielnych aplikacji: Sprzedaż i marketing.
Aplikacja sprzedażowa emituje event "budżetowy", a następnie aplikacja marketingowa reaguje na to wydarzenie wysyłając kampanię marketingową.
Jakie są korzyści z tego wynikające ?
Te koncepcje zwiększają jakość oprogramowania, ale trzeba być rozsądnym podczas projektowania systemu.
Wydarzenia domenowe i integracyjne mogą ułatwić Ci życie, ale musisz dbać o to, kiedy jest to potrzebne. Na przykład, jeśli potrzebujesz stworzyć prostą aplikację CRUD, a nic więcej się nie dzieje, na pewno nie musisz projektować ogromnej architektury, aby to obsłużyć. Po prostu bądź rozsądny i zachowaj prostotę.