Integracja aplikacji ze sobą za pomocą Apache Kafka jest stosunkowo łatwa. W tym zadaniu wspomagają nas biblioteki albo całe frameworki (takie jak Spring). Ponieważ to zadanie jest znacznie ułatwione, może to uśpić czujność programistów. Chciałbym zwrócić Twoją uwagę na to, żebyś poświęcił chwilę na analizę wymagań niefunkcjonalnych w swojej aplikacji, a także zapoznał się z domyślnymi ustawieniami Apache Kafka i bibliotek integrujących.
Korzystając z Hibernate czy też Java Persistence API dla konfiguracji mapowania danych i operacji korzystasz z mapowania dla encji, operacji i relacji. Ale Hibernate dostarcza dodatkowych anotacji, z których chciałbym Ci przedstawić kilka wybranych.
Uwielbiam kod, który nie zaskakuje. Kiedy praca na modelu domenowym ułatwia rozwiązywanie problemu. Kiedy pojęcie w systemie jest spójne i nie czyhają na mnie dodatkowe pułapki związane z tym, że zaraz użyję istniejącego już fragmentu.
Właściwie w takim celu powstaje model dziedzinowy (domain model) – żeby za pomocą zdefiniowanych pojęć, które wyrażają: agregaty, parametry procesu lub jego wynik, pomogły mi ich użyć w przewidywalny sposób.
Dlatego wolę, żeby niewłaściwie użyty kod wywrócił się od razu, niż ukrył problem, którego skutki objawią się w innym, dalszym miejscu w procesie.
Takie podejście/technika nazywa się Fail fast.
Istnieje powód, dla którego korzystamy ze zmiennych prywatnych w naszych klasach. Nie chcemy ich udostępniać na zewnątrz i nie chcemy, aby ktoś na nich polegał. Uczono nas, że publiczne zmienne w klasie to zło. Dlaczego więc tak wielu programistów „automatycznie” dodaje gettery i settery do swoich modeli, sprawiając, że prywatne zmienne są widziane na zewnątrz? Nie raz pewnie widziałeś w kodzie adnotacje Lomboka @Setter, @Getter czy @Data nad większością klas. W dzisiejszym wpisie przyjrzymy się bardziej szczegółowo często pomijanej kwestii akcesorów, mutatorów, a następnie przejdziemy do omówienia Anemic Domain Model oraz Rich Domain Model.
Tworząc systemy, które wymieniają dane z bazą danych, chcesz, aby komunikacja była niezawodna.
Możesz wykonywać operacje, które mogą być krótkie, ale za to częste, a może będziesz wykonywał takie, które są bardzo długie.
Operacje są wykonywane w ramach nawiązanego wcześniej połączenia do bazy.
Użytkowników systemu przeważnie jest wielu, a ich sesje powinny być niezależne.
W pewnym momencie może się zdarzyć, że użytkownik nie będzie mógł wykonać jakiejś operacji,
ponieważ baza danych odrzuci kolejne połączenie ze względu na jakiś limit.
Ale przez odpowiednią konfigurację możesz zoptymalizować szybkość działania Systemu w zakresie dostępu do nawiązanego
połączenia do bazy danych.
Konsument Kafki jest używany do optymalnego odczytywania wiadomości z partycji topika, który subskrybuje. Główną rolą konsumenta jest wziąć połączenie do klastra Kafki oraz ustawienia konsumenta, aby połączyć się z brokerem i zacząć odczytywać wiadomości.