Posty z tej serii:

W poście Wytwarzanie oprogramowania IV, na przykładzie NServiceBus’a, widzieliśmy jak Messaging and Queueing stawia krok do przodu w kierunku polepszenia jakości realizowanych systemów. Ten post otwiera serię pokazującą jak za pomocą tej samej techniki zrealizować system dodawania komentarzy do bloga. Trzy główne wątki tego posta to: Idea, User Stories oraz Design rozwiązania.

Idea

Używając Jekyll’a jako silnika do blogowania mamy możliwość hostowania zawartości na serwerach GitHub’a przy pomocy GitHub Pages. Każdy nowy post to git-push do repozytorium kodu. Każdy komentarz można więc potraktować jako GitHub pull request do opublikowanego posta.

User Stories

Trzy podstawowe wymagania opisane za pomocą techniki User Story mogą wyglądać tak:

  1. Jako czytelnik bloga chcę dodać komentarz do przeczytanego posta
  2. Jako autor bloga chcę zweryfikować, a następnie odpowiedzieć na dodany komentarz lub go odrzucić
  3. Jako czytelnik bloga chcę być poinformowany o rezultacie dodanego przeze mnie komentarza do posta

Design

Poniższy diagram przedstawia projekt rozwiązania na platformę .NET z użyciem:

Picutre1

Na diagramie numerki od 1 do 22 przedstawiają kolejność wykonywania poszczególnych kroków, a poszczególne strzałki oznaczają rodzaje operacji:

  • <—> - wywołanie Request\Response
  • —-> - wysłanie wiadomości do kolejki\zlecenie działania (command)
  • ….> - wysłanie wiadomości do kolejki\poinformowanie, że działanie zostało zakończone (event)

Przeanalizujmy diagram krok po kroku:

  • 1 - komentarz przychodzi w postaci żądania HTTP
  • 2 - moduł webowy tworzy message z danymi typu command i wysyła go do kolejki
  • 3 - moduł webowy zwraca odpowiedź w stylu “dziękuję twoje zgłoszenie zostało przyjęte”
  • 4 - message handler podnosi message z kolejki i wysyła kolejny message z żądaniem utworzenia na GitHub'e nowego branch’a z branch'a master gdzie znajduje się post
  • 5 - message handler podnosi message z kolejki i używając GitHub API tworzy branch'a
  • 6 - GitHub API zwraca odpowiedź
  • 7 - message handler publikuje message typu event z informacją, że branch został utworzony
  • 8..9..10..11 - na tej samej zasadzie jak w krokach od 4 do 7 wykonywana jest operacja dodania komentarza do posta na nowo utworzonym branch'u
  • 12..13..14..15 - na tej samej zasadzie jak w krokach od 4 do 7 wykonywana jest operacja utworzenia pull request'a
  • 16 - message handler wysyła message do siebie samego w stylu “mam się zbudzić z X minut”
  • 17..18..19..20 - message handler wybudza się oraz sprawdza stan pull request'a
    • jeśli pull request jest otwarty, sterowanie wraca do kroku 16
    • jeśli pull request jest zamknięty sterowanie przechodzi do kroku 21
  • 21..22 - message handler podnosi message z kolejki i wysyła email z informacją w stylu:
    • “do komentarza została dodana odpowiedź”, jeśli pull request został z'merge'owany z master'em i zamknięty
    • “komentarz został odrzucony”, jeśli pull request został zamknięty bez merge'a z master'em

Punkty od 1 do 16 realizują User Story nr 1. natomiast punkty od 17 do 22 realizują User Story nr 3. Gdzie jest zatem realizacja User Story nr 2.? Tutaj niestety “samo się nie zrobi”. Aby zweryfikować posta można skorzystać z portalu GitHub'a dodając odpowiedź i merge'ując pull request'a do master'a lub odrzucając komentarz poprzez samo zamknięcie pull request'a.

Punkt nr 16 pokazuje interesującą rzecz. Pomiędzy dodaniem komentarza, a jego obsługą może upłynąć dość długi czas. Powoduje to, że całość staje się tak zwanym Long-running Business Process. Taki proces w języku NServiceBus'a reprezentowany jest jako Saga. Na diagramie rolę Sagi pełni Message Handler Saga. Saga to również odpowiednik jednego ze wzorców Enterprise Integration Patterns (EIP) zwanego Process Manager.

To tyle w temacie projektowania rozwiązania. W następnym poście zobaczymy w jaki sposób można zaimplementować powyższe rozwiązanie.

=