Skip to content

Latest commit

 

History

History
99 lines (74 loc) · 6.53 KB

README.md

File metadata and controls

99 lines (74 loc) · 6.53 KB

banner Szukasz wersji kodu, do ktorej odnosimy sie w kursie? Zajrzyj na branch kurs.

Czym jest projekt GroupFlights?

GroupFlights to projekt systemu realizujacego obsluge grupowych biletow lotniczych. To repozytorium przedstawia wynik calego proces wytwarzania oprogramowania w oparciu o Domain-Driven Design uwzgledniajac:

  • discovery stanu AS-IS
  • discovery stanu TO-BE
  • destylacje subdomen
  • projektowanie bounded contextow
  • projektowanie integracji bounded contextow
  • taktyke, tj, implementacje w oparciu o decyzje podjete na poziomie strategicznym

Suplementem do tego repozytorium jest publiczny board na Miro:

miro

Z samym procesem "od A do Z" mozesz zapoznac sie w ramach naszego kursu Domain-Driven Design "Pragmatycznie: https://domain-driven-design.net/

Jak uruchomic?

Uruchamiamy wymagana infrastrukture:

docker-compose up -d

Nastepnie uruchamiamy bramke platnosci:

dotnet run --project src/_ExternalSystems/FakePaymentGateway/FakePaymentGateway.csproj

I w koncu nasza glowna aplikacje:

dotnet run --project src/Api/GroupFlights.Api/GroupFlights.Api.csproj

Na starcie aplikacji zostana uruchomione migracje, ktore zaloza wszystkie wymagane struktury w bazie danych.

Jesli zajdzie potrzeba, mozesz usunac wszystkie informacje z bazy danych bez potrzeby jej przegenerowywania uzywajac skryptu: truncate-everything.sql

Mapa procesu wytwórczego

By lepiej zrozumiec droge, jaka nalezy przejsc w ramach czesci strategicznej Domain-Driven Design warto zapoznac sie z n/w mapa procesu wytworczego:

...

Inspiracja: https://github.com/ddd-crew/ddd-starter-modelling-process

Zalozenia

  • Na architekture wdrozeniowa wybrano modularny monolit
  • Jako baze danych wybrano Postgres
  • Separacja modelu danych poszczegolnych modeli opiera sie o oddzielne schematy w ramach jednej bazy danych
  • Zaleznosci pomiedzy modulami realizowane sa przy uzyciu tzw. shared contracts; wiecej o tym w ADR:
  • W zaleznosci od poziomu skomplikowania oraz klasy rozwiazywanych problemow, architektura aplikacyjna to:
    • CRUD,
    • Clean Architecture
    • CRUD+rich domain model
  • Nie implementujemy uwierzytelnienia ani autoryzacji; naiwna "imitacja" tych funkcjonalnosci opiera sie o naglowki X-UserId i X-CashierId, ktore zderzane sa z deklaracja w definicji endpointu: NaiveAccessControl
  • System nie korzysta z zadnego zewnetrznego brokera wiadomosci. Elementy asynchronicznosci realizowane sa poprzez in-memory message dispatchera (ktory celowo z opoznieniem i poza transakcja dispatchuje zebrane zdarzenia): EventDispatcher
  • Projekt zawiera tylko przykladowe testy jednostkowe, tak by zaprezentowac roznice pomiedzy testowaniem modelu z publicznymi getterami w OfferDraftTests oraz modelu w pelni zenkapsulowanego, bez dostepu do pol i wlasciwosci ReservationChangeRequestTests
  • Na potrzeby dydaktyczne projekt implementuje trzy podejscia do persystencji:
  • System nie implementuje bramki e-mail ani notyfikacji, a jedynie przyklad wysylki e-mail poprzez zapis komunikatu do konsoli
  • System nie implementuje integracji z zadnym systemem platnosci; zamiast tego opracowano sztuczna bramke imitujaca takie zachowanie wraz z "auto-platnosci" po 5s

Dostepne scenariusze (./src/_Scenarios)

Dla uproszczenia przechodzenia przez poszczegolne kroki procesu biznesowego udostepnilismy pliki .http.

Do ich uruchomienie niezbedne jest IDE takie jak: VSCode lub JetBrains Rider.

Scenariusze nalezy wykonac w nastepujacej kolejnosci:

  1. Dodanie zgloszenia przez potencjalnego klienta: add-inquiry.http
  2. Akceptacje zgloszenia przez kasjera: accept-inquiry.http
  3. Dodanie wariantu lotu przez kasjera: add-variant.http
  4. Potwierdzenie wariantu lotu wraz z jego kosztem przez kasjera: confirm-variant.http
  5. Prezentacje oferty klientowi przez kasjera: reveal-offer-draft.http
  6. Akceptacje oferty przez klienta: accept-offer.http
  7. Przegladanie rezerwacji: browse-reservations.http
  8. Pobranie wygenerowanej umowy przez klienta(1): download-contract.http
  9. Podpisanie wygenerowanej umowy przez klienta(1): upload-contract.http
  10. Podanie naziwsk pasazerow przez klienta(2): set-passengers-for-flight.http
  11. Dodanie platnika przez klienta: add-payer.http
  12. Ustalenie platnosci po zatwierdzeniu rezerwacji przez kasjera: setup-reservation-payment.http
  13. Deklaracje zmiany rezerwacji przez klienta(2): request-travel-change.http
  14. Ustawienie "robialnosci" zmiany przez kasjera: set-change-feasibility.httpp

(1) Identyfikator umowy znajduje sie na rezerwacji, ktora wyszukasz uzywajac browse-reservations.http

(2) Identyfikator rezerwacji znajduje sie na rezerwacji, ktora wyszukasz uzywajac browse-reservations.http

Wsparcie

discord