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
  • 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