Świat tworzenia oprogramowania przeszedł drastyczną transformację w ciągu ostatnich 15 lat. Od czasów, gdy programiści skupiali się po prostu na uruchomieniu projektu wdrożeniowego lub architektury. Do dnia dzisiejszego, w którym od programisty oczekuje się zarządzania całym procesem produkcyjnym, od zrozumienia potrzeb i problemów klienta po dostarczenie wartości. W tym miejscu pojawia się Domain-Driven Design (DDD). DDD to podejście do tworzenia oprogramowania, które pomaga budować spójne systemy, które można szybko i łatwo dostosować do zmieniających się wymagań aplikacji. Na tym blogu omówimy zalety korzystania z DDD i jak skutecznie je wdrożyć.

Czym jest Domain-Driven Design?

Domain-driven design to podejście do tworzenia oprogramowania dla złożonych potrzeb poprzez głębokie połączenie implementacji z ewoluującym modelem podstawowych koncepcji biznesowych. Nacisk na wiedzę o domenie i zrozumienie, w jaki sposób użytkownik końcowy będzie korzystał z oprogramowania w kontekście biznesowym, czyni go szczególnie przydatnym przy tworzeniu oprogramowania dla przedsiębiorstw.

U podstaw DDD leżą dwie rzeczy:

  1. Język Ubiquities: używanie tego samego języka, którego używają eksperci domeny w programach. Powoduje to, że piszemy kod w sposób, w jaki napisałby go ekspert domeny.
  2. Modele domeny: strukturyzacja kodu w sposób, który hermetyzuje logikę biznesową i ułatwia jej zmianę.

W skrócie - Domain-driven design koncentruje się na opracowaniu modelu domeny, który programiści mogą wykorzystać do stworzenia rozwiązania programowego spełniającego określone potrzeby klienta.

Jak można zaprojektować rozwiązanie problemu, którego się nie rozumie?

DDD NIE jest srebrną kulą dla wszystkich problemów związanych z tworzeniem oprogramowania. Nie zalecałbym używania DDD do zadań z prostymi rozwiązaniami. Ale może być bardzo skuteczny w pewnych sytuacjach, szczególnie podczas tworzenia dużych aplikacji korporacyjnych. Naszym zadaniem jako inżynierów oprogramowania jest tworzenie rozwiązań spełniających potrzeby naszych klientów. A nie można tego zrobić, jeśli nie rozumie się problemu lub nie jest się w niego zaangażowanym od samego początku. Idealna sytuacja dla klienta to taka, w której opisuje on problem, a ty, jako inżynier, opisujesz rozwiązanie. Możemy to zrobić tylko wtedy, gdy rozumiemy biznes.

Domain-driven design to podejście do tworzenia oprogramowania, które koncentruje się na dogłębnym zrozumieniu domeny problemu. Zrozumienie to jest wykorzystywane do kierowania rozwojem oprogramowania. Weźmy na przykład moją ostatnią podróż do Niemiec. Jestem w stanie odwiedzić moich klientów (przeczytaj więcej o Beckerbillett tutaj). Praktyczne zapoznanie się z technologią pozwoliło mi zrozumieć, jak oferować rozwiązania odpowiadające ich potrzebom.

Naszym zadaniem jest oferowanie najlepszych rozwiązań, a stosowanie podejścia DDD ułatwia projektowanie systemów dla klientów. I moim zdaniem jest to ogromny przełom. Nie powinieneś być tylko programistą, powinieneś być projektantem. Powinieneś projektować rozwiązania problemów, a ignorując podejście DDD zamykasz sobie drzwi i możliwości.

Kolejnym elementem układanki dla projektów jest liczba sposobów podejścia do sytuacji. Obecnie mamy nadmiar narzędzi, wzorców i sposobów na rozwiązanie dowolnego problemu, takich jak TDD, BDD, wzorce projektowe, wzorce aplikacji itp. Bardzo ważne jest, aby zrozumieć, dlaczego czegoś używamy. Co więcej, wiedza o tym dlaczego powinna być dzielona z całym zespołem. Ponadto większość systemów sprowadza się do tworzenia aplikacji, która już istnieje gdzieś na świecie. To całe przeciążenie popchnęło inżynierów w drugą skrajność i powstało zjawisko overengineeringu. Wykorzystując to, co modne do rozwiązania problemu, do czego może prowadzić takie zjawisko? Odpowiedź sugeruje powstanie niekontrolowanego długu technicznego i porażkę projektu.

Jak tego uniknąć? Ponownie, zrozumieć biznes klienta i zaprojektować rozwiązanie odpowiadające jego potrzebom. Aby osiągnąć ten cel, DDD wykorzystuje szereg technik, w tym modelowanie domeny i Event Storming.

Czym jest Event Storming?

Event Storming to elastyczny format warsztatowy do wspólnej eksploracji złożonych domen biznesowych, który może być wykorzystywany do oceny kondycji istniejącej linii biznesowej; odkrywania najbardziej efektywnych obszarów do poprawy; badania rentowności nowego modelu biznesowego startupu; wyobrażania sobie nowych usług, które maksymalizują pozytywne wyniki dla wszystkich zaangażowanych stron; oraz projektowania czystego i łatwego w utrzymaniu oprogramowania sterowanego zdarzeniami. Adaptacyjny charakter Event Storming umożliwia interdyscyplinarną rozmowę pomiędzy interesariuszami z różnych środowisk, pozwalając na nowy rodzaj współpracy poza granicami silosów i specjalizacji.

Jak doszliśmy do modelu projektowania opartego na domenie?

Podzieliłbym programowanie na kilka okresów. Pierwszym etapem było pojawienie się języków obiektowych. Wszystkie programy były pisane tak, jak je rozumiano lub jak inżynier wiedział, jak napisać dla danego wymagania biznesowego. Analitycy biznesowi ustalali listę zadań, programiści wybierali jedno, kodowali dla niego i to wszystko. Miało to jedną poważną wadę, programiści byli ograniczeni tylko do wybranych części procesu projektowania. Ograniczało to ich zaangażowanie i wpływało na sposób podejścia do problemu. DDD rozwiązuje ten problem poprzez umieszczenie inżynierów na początku procesu projektowania. Dając inżynierom możliwość wypowiedzenia się na temat całego procesu, pomaga stworzyć dostosowaną odpowiedź na potrzeby klienta.

Kolejnym etapem był etap prowadzący do stworzenia DDD (domain-driven design) w 2005 roku. W tamtym czasie inżynierowie próbowali modelować zachowania biznesowe w obiektach, aby jakoś je połączyć, ale granica wciąż stanowiła problem. Jeśli program był tworzony przez jednego inżyniera, było w porządku, ale jeśli kilku inżynierów pracowało nad jednym programem, pojawiały się problemy. DDD rozwiązało ten problem, kładąc nacisk na inżynierów określających przepływ pracy w projekcie.

Czy korzystanie z tego, co darmowe, naprawdę przebija Domain-Driven Design?

Jest jeszcze jeden czynnik w tej całej układance oprogramowania open-source. Istnieje wiele kodów, które są dostępne za darmo z możliwością ich komercyjnego wykorzystania. Po co zatrudniać zespół, skoro można mieć coś za darmo w tydzień?

Krótko mówiąc, bycie darmowym nie oznacza, że będzie działać dla ciebie. DDD to skuteczne podejście do tworzenia oprogramowania. Pomaga programistom rozwinąć głębokie zrozumienie domeny problemu. Ograniczenie dewelopera do tego, co jest dostępne po najniższych kosztach, ogranicza sposoby, w jakie może on podejść do danej sytuacji. Może to spowodować zły start projektu i wpłynąć na dług techniczny i fundamenty projektu. Jest to duży problem, jeśli w przyszłości zajdzie potrzeba zwiększenia skali projektu. Lepszym rozwiązaniem jest zapewnienie inżynierom technologii, która najlepiej pasuje do problemów biznesowych. Jedynym sposobem na to jest zrozumienie potrzeb biznesowych już na wczesnych etapach planowania. Zmniejsza to ryzyko powstania długu technicznego i chroni projekt na przyszłość.

Wdrożenie Domain-Driven Design jest najlepsze dla biznesu

Na podstawie tego wszystkiego mogę powiedzieć, że kod to biznes. Jeśli robisz coś dokładnie tak, jak wszyscy inni, musisz konkurować ceną. Konkurowanie ceną oznacza, że trzeba mieć głębokie kieszenie lub najkrótszy łańcuch dostaw na świecie. Jeśli kod jest biznesem, potrzebujesz inżynierów, którzy są świadomi biznesu, rozumieją go i pomagają go ulepszać.

Moja rada brzmi: napisz swój główny biznes, chroń go i dostosuj jak nikt inny, wszystko inne można zintegrować. Jeśli twój biznes wyróżnia się na rynku w taki sposób, że klienci to docenią, to jesteś na wygranej pozycji. Jako inżynier oprogramowania ważne jest, aby dobrze rozumieć biznes, aby skutecznie rozwiązywać problemy swoich klientów. Bez tego zrozumienia może być trudno w pełni zrozumieć zakres i wymagania projektu, co prowadzi do potencjalnych błędów i nieporozumień.

Jeśli chcesz porozmawiać więcej na ten temat, skontaktuj się z nami.

4.8/5 - (32 głosy)