Wprowadzenie do Domain Driven Design: Dlaczego Domain Driven Design

0:02Zanim konkretnie omówimy części składowe Domain Driven Design, musimy odpowiedzieć

0:07sobie na pytanie po co stosować te metodologie?

0:10Dlaczego Domain Driven Design w Twoim projekcie?

0:14Domain Driven Design jest to metodologia, która koncentruje się na potrzebach

0:17biznesowych i na komunikacji z biznesem na komunikację między

0:21programistami a biznesem.

0:23A efektywna komunikacja to przede wszystkim język.

0:27A jeśli chcemy mieć wspólny język, to musimy utworzyć taki zestaw pojęć i

0:31terminologii, który będzie jednakowo rozumiany przez obie strony, przez stronę

0:35biznesową, nie techniczną, jak i przez stronę techniczną, czyli po prostu przez

0:39programistów dział nazwijmy to produktowy.

0:44I ta strona produktowa będzie miała często pokusę, żeby stosować

0:49nomenklaturę technologiczną.

0:51My, programiści lubimy operować trudami, operować kontrolerami, modelami, stosami,

0:57emocjami i innego tego typu słownictwem, które jest czysto technologiczne.

1:02Biznes nie rozumie, co to jest record w bazie danych, co to jest indeks.

1:07Biznes nie będzie się tym interesował, bo domeną biznesu jest skupienie się na

1:11problemach i na rozwiązywaniu problemów biznesowych oraz na tym, żeby tak

1:16projektować produkt, aby przynosił on wartość klientom.

1:19Programiści skupiają się z kolei na tym, żeby te wymagania biznesu przekuć na kod.

1:24Dlatego tak ważny jest wspólny język i.

1:27Domain Driven Design to metodologia, która narzuca nam albo wymusza stworzenie tego

1:32wspólnego języka pomiędzy biznesem a programistami.

1:36Wspólny język stanowi pewien pomost, stanowi zestaw pojęć, który tak

1:40programiści, jak i część biznesowa rozumieją w ten sam sposób.

1:44Kolejnym aspektem jest koncentracja na tych potrzebach biznesowych.

1:48Odchodzimy tutaj od projektowania aplikacji w taki sposób, aby to te

1:53techniczne drivery decydowały o jej strukturze.

1:56Nie będziemy tutaj szli w architekturę warstwową, w której możemy mieć np.

2:00architekturę typu MVC, gdzie mamy modele, widoki, kontrolery.

2:04Będziemy tworzyć bardziej złożoną strukturę, złożoną strukturę, która z

2:09kolei będzie miała mocne odwzorowanie w biznesie.

2:14Albo to inaczej biznes będzie miał odwzorowanie w strukturze, bo my jako

2:18programiści w Domain Driven Design będziemy koncentrować się na realizacji i

2:22odwzorowaniu jak najwierniejszym odwzorowaniu reguł biznesowych i

2:26potrzeb w kodzie Domain Driven Design.

2:28Ze względu na to, że koncentruje się na domenie, na potrzebach biznesowych,

2:34Umożliwia łatwiejsze zarządzanie złożonością projektu.

2:37Nie potrzebujemy przebijać przez warstwy, które narzuca nam technologia, ale

2:42jesteśmy w stanie nawigować się pomiędzy biznesowymi pojęciami,

2:45które są zakodowane.

2:46Będziemy mieć nomenklaturę biznesową w kodzie.

2:49Będziemy mieć wydzielone konteksty biznesowe, które będą miały z kolei

2:53odwzorowanie w strukturze klas i w strukturze danych.

2:56Skalowalność i złożoność tego systemu będzie łatwiejsza do zarządzenia, bo

3:01będzie odwzorowywać niejako strukturę organizacji, a co za tym idzie

3:05zyskamy pewną spójność danych.

3:07Bo złożoność, która jest dobrze zarządzana charakteryzuje się stabilnością

3:12i spójnością danych.

3:14Jednym z ważnych aspektów projektowania sterowanego domeną jest

3:18identyfikacja zdarzeń biznesowych.

3:20To zdarzenia biznesowe będą wyznaczać nam operacje logiczne w aplikacji.

3:25Wreszcie umożliwia to strategiczne planowanie ze względu na to, że

3:29to biznes przychodzi z potrzebami.

3:31I programiści są niejako częścią tego biznesu i mówią tym samym językiem.

3:35Strategiczne planowanie do przodu, tworzenie kontekstów będzie o wiele

3:39prostsze dzięki Domain Driven Design, a co za tym idzie jesteśmy w stanie wydzielać

3:44autonomiczne konteksty, które wykonują pewne powtarzalne, modelowe operacje.

3:50I te operacje, te zestawy operacji, zestawy struktur, klas, struktur kodu

3:56będą mogły stanowić używane rozwiązania.

3:59Wiele jest systemów typu e-commerce, np.

4:02do zarządzania projektami, do zarządzania flotą, gdzie pewne operacje, pewne

4:07konteksty są bardzo podobne lub są niemalże jednakowe np.

4:11invisible, wystawianie faktur, jeden Jeden moduł do wystawiania faktur może stanowić

4:16używane rozwiązanie w różnych systemach i być wykorzystywany w ten sam sposób.

4:21Na koniec metodologia Domain Driven Design nie istniałaby bez współpracy programistów

4:26z biznesem i głównie ta współpraca stanowi podstawę skuteczności implementacji Domain

4:33Driven Design jako drivera architektonicznego jako

4:37wyznacznika architektury oprogramowania.