Please enable JavaScript.

Coggle requires JavaScript to display documents.

Legacy Fighter - Coggle Diagram

- - - - w przypadku plików zmieniających się czesto
  - - - Zwykle rozpoczynamy pracę od „Big Picture”, czyli wysokopoziomowego spojrzenia na problem. Ułożenie zdarzeń na osi czasu, wzbogacenie ich o powiązanych aktorów, zaangażowanie w proces systemów zewnętrznych, przepływy wartości materialnych i niematerialnych, pomysły na możliwe usprawnienia, ale przede wszystkim zidentyfikowanie potencjalnych ryzyk czy problemów, pozwala na bardzo dobre rozpoznanie tematu i wybranie miejsc do dalszej eksploracji.
    - - Eksplorację tę będziemy kontynuować, korzystając z tzw. Process Level EventStormingu, w którym nasz zestaw elementów konstrukcyjnych rozszerza się o koncept kierowanego do procesu rozkazu (komendy, a więc żądania o zmianę), danych potrzebnych aktorowi do podejmowania takich decyzji oraz polityki, dzięki której możemy opisywać bardziej złożone i długotrwałe procesy.
    - - Na końcu, mając wiedzę o potrzebnych w systemie funkcjach, korzystając z Design Level EventStormingu, czasem także nazywanym Software Design ES, możemy zaproponować strukturę rozwiązania technicznego, np. występujących w systemie obiektów i ich odpowiedzialności. A to jest już coś, co bezpośrednio przekłada się na prace implementacyjne w projekcie.
    - - możemy skorzystać z bardzo uproszczonego Big Picture EventStormingu, podczas którego skupimy się jedynie na zmapowaniu zachodzącym w systemie zdarzeń zmieniających jego stan. Pamiętając jednak, aby opisać każde z nich językiem biznesowym. „Zmieniających jego stan” jest tu często szczególnie istotne, ponieważ przystępując do refaktoryzacji projektu legacy zwykle nie będziemy zainteresowani jego szerszą biznesową analizą czy też wpływem na systemy zewnętrzne. Obserwowalne zachowania powinny pozostać niezmienione.
      - Obserwowalnymi zachowaniami będą zidentyfikowane w trakcie warsztatu zdarzenia domenowe. Znając zarówno zlecany przez użytkownika systemu rozkaz, jak i wszystkie oczekiwane obserwowalne zachowania, jesteśmy w zasadzie o krok od sformalizowania oczekiwań biznesowych.
- - - - ● spójność może się objawiać potrzebą sprawdzenia reguł przed zmianą danych albo potrzebą zmieniania kilku danych kaskadowo (dane zawsze zmieniają się razem)
      - ● obiekt który posiada same settery i gettery jest strukturą danych, którą można wprowadzić w dowolny stan (złamać spójność)
  - - - Strategie rozwiązania
        problemu write-write
        
        ostatni wygrywa, dopuszczamy tu możliwość nadpisania
        nowszego stanu w bazie danych
        
        pierwszy wygrywa, wymagamy tu zmiany najświeższej
        wersji stanu, za pomocą blokowania optymistycznego**
      - write read
      - read read
    - - pozwala na zachowanie spójności danych ale nie zawsze jest nam potrzebny - przykład z aktualizacją wartości licznika ilości samochodów - czasem wartośc zmiennej może być dla nas jedynie estymatą
      - powoduje problem powstawania konfliktów
    - - powoduje LOST Update
        
        rozwiazanie: eliminacja ryzyka zgubienia aktualizacji stanu, poprzez inkrementację i dekrementację licznika za pomocą
        czystych instrukcji SQL
    - - Co się dzieje z tymi danymi?
        
        W jaki sposób są one wykorzystywane?
        
        W jakim celu zostały one wyświetlone?
        
        Czy na ich podstawie są podejmowane ważne decyzje biznesowe?
      - Jeśli jakieś dane są ze sobą związane silną regułą,
        należy zapewnić ich spójność zarówno podczas zapisu jak i odczytu. np. dane na fakturze lub w systemie medycznym; składanie odczytów z kilku zapytań może skutkować rozsynchronizowaniem danych
    - - Czy można zauważyć okresy o większej/mniejszej
        dostępności funkcji systemu?
        
        Czy w logach produkcyjnych można zauważyć błędy
        potencjalnie związane z zapisami i z blokowaniem
        optymistycznym?
        
        W jaki sposób projektowany/refaktorowany obiekt będzie
        używany? Ile różnych akcji biznesowych będzie go
        zmieniać? Jak często się będą się one wykonywać?
        
        Czy problem dotyka wszystkich, czy tylko wybranego klienta?
      - Jak go naprawić?
        
        Zidentyfikuj problematyczna daną
        
        Odseparuj daną
        
        Określ sposób migracji danych pomiędzy strukturami
        
        Zastanów się nad potrzebą stosowania blokowania
        optymistycznego podczas zapisu
        
        Użycie poszczególnych narzędzi, technik i wzorców
        dopasowujemy zawsze do konkretnej sytuacji projektu i jego
        problemów.
- - - - stabilny interfejs sprawia ze zmiany wprowadzane za jego granica sa zmianami lokalnymi, nie maja wplywu na klientow interfejsu
      - Duzo łatwiej zmienia sie kod jesli otoczony jest stabilnym interfejsem. Nawet jesli nie jest on czysty i zmienny to stabilny interfjes ukrywa to przed klientami.
      - zdefiniuj obserwowalne zachowania
      - nie ujawniaj szczegolow implementacyjnych
      - stabilny interfejs sprawia ze "stojacy za nim" kod jest łatwo usuwalny