markaron
  • 1
Nietrywialny problem. Jest system A, który ma za zadanie pobierać dane z B i wysyłać do C. W jaki sposób rozwiązalibyście problem synchronizacji danych w taki sposób, aby do systemu C wysyłać tylko nowe dane, czyli takie, które nie zostały do tej pory przetworzone. Dane z systemu B można otrzymać wysyłając żądanie pod przykładowy adres /api/products który zwraca listę wszystkich produktów.

Najprostszym rozwiązaniem jest przechowywanie przez system A lokalnie metadanych produktów które
  • 13
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
phosphor-bronze
phosphor-bronze
  • 1
@markaron: jeśli nie masz możliwości weryfikacji co jest już w C lub czy C zapisał poprawnie dany batch, to generalnie jesteś w miejscu gdzie plecy tracą swą szlachetną nazwę :) BTW interfejs systemu B jest słaby skoro nie ma możliwości wysłania parametrów filtrowania, co jak produktów będzie milion? System B powinien mieć filtrowanie, dane z unikalnym kluczem, ew mógłbyś haszować jeśli klucza nie ma i deduplikowac na tym haszu. Reasumując,
  • Odpowiedz
MacDada
  • 1
#ddd […] Mamy tabelę w bazie o dużej ilości kolumn (np. 20) bez możliwości jej edycji (np. baza została zaprojektowana przez zespół bazodanowy)


@markaron: I w tym momencie to już nie jest Domain Driven Development, tylko Database Driven Development -> dwia odwrotne założenia.

W DDD programista rozmawia z ekspertami domeny. Dowiaduje się jak wygląda domena z różnych perspektyw. Modeluje to w kodzie. Obiekty, ich struktura, cechy, walidacja – wszystkie te
  • Odpowiedz
MacDada
  • 1
@markaron: Nie, DDD jest wtedy, gdy projektujesz obiekty na podstawie wiedzy domenowej. A dopiero potem myślisz o bazce.

Jak już bazkę masz, to być może jej struktura podpowie Ci pewne rzeczy „słuszne” w domenie. Np jak masz tabelę „badania” i posiada ona kolumnę „ciśnienie” to już wiesz, że „ciśnienie jest czymś, co opisuje badanie”. Być może „badanie” ma relację z „pacjenci” => i z tego znów już wiesz, że badanie może
  • Odpowiedz
michalfranc
michalfranc
  • 1
@markaron: nie rozumiem co zlego widzisz w fajnej obsludze tupli. Jakich zmian oczekiwalbys wiec od C# 7 ? To juz tylko bedzie ewolucja, malo rewolucji. Raczej takie wlasnie p-------i ktore niektorym osoba ulatwia zycie.

W jaki sposob te lukry utrudniaja zrozumienie kodu, to od developera zalezy czy kod bedzie zrozumialy czy nie.
  • Odpowiedz
markaron
  • 0
@MacDada: Czytałem, wszystkie artykuły czytam przed wrzuceniem. Słowo cierpień tyczyło się tego ile problemów i dyskusji wiąże się z implementacją Repository i że to co jeden programista uzna za słuszną implementację, to znajdzie się inny, który to zaneguje. Tyle. Z resztą napisałem, że w komentarzach jest ciekawa dyskusja na temat tego jak implementować Repository. Sorry, ale się czepiasz.
  • Odpowiedz

Marek

  • Back-endowiec dotNetowiec

Osiągnięcia