Gdzieś mi przemknął taki test ma to, czy DDD na sens w Twoim projekcie:
JEŚLI: Myślisz o swojej aplikacji jako o warstwach
I JEŚLI: Na samej górze jest zawsze web
I JEŚLI: Na samym dole jest zawsze baza danych
TO: Nie masz do czynienia z czymś takim jak "domena"
TO: DDD jest Ci niepotrzebne
[update: 28.02]
JEŚLI: Wyobrażasz sobie architekturę swojej aplikacji jako "stos"
I JEŚLI: Na samej górze tego stosu jest zawsze web
I JEŚLI: Na samym dole tego stosu jest zawsze baza danych
TO: To prawdopodobnie dziedzina, którą informatycznie wspierasz nie jest zbyt złożonna
TO: Wprowadzenie Domain Model za pomocą DDD będzie nieadekwatne do potrzeb i zbyt kosztowne
Ponieważ uwielbiam metafory, szukałem jakiejś trafnej historyjki dla tego kejsu i przyszło mi do głowy coś takiego:
Serce: Słuchaj, Mózg, czy armata to dobra broń?
Mózg: Hmmm, no bardzo dobra...jeśli chcesz zdobyć Fort Knox, ale jeśli chcesz po prostu przetrzepać skórę paru cwaniakom, to powinieneś zastanowić się nad czymś tańszym.
Nic bardziej mylnego:)
ReplyDelete1. Tier (np. maszyny: servery różnego rodzaju, klienty) to nie Layer (warstwy kodu o wyróżnionej odpowiedzialności)
2. Soft biznesowy (bo w taki głównie celuje DDD) ciężko sobie wyobrazić bez jakiegoś rodzaju "wziernika" do wybranych wnętrzności i bez jakiegoś rodzaju persystencji (więc warunek jest zbędny)
3. dziedzina jakaś jest zawsze. zawsze
Warunek jest prosty: wycinek dziedziny jest dostatecznie złożony lub skomplikowany (tak zwany Core Domain).
Trudne pytania: skąd wiadomo i po czym poznać, że tak jest? Czy da się to orzec nie mając dostatecznie dużo odnośnych doświadczeń i wiedzy o tym jakie podejścia są możliwe?
bardzo fajne, moja metafora: jeżeli celem nie jest samochód a jedynie rower to czy nie lepiej go po protu pospawać zamiast skręcać go z jakichś standaryzowanych elementów standardowymi śrubkami? No niech popatrzę na te najfajniejsze rowery na ulicy... kurcze czemu Ci ludzie tak komplikują te rowery????
ReplyDeletePrzyszła mi jeszcze na myśl taka metafora (z której można wyłonić strategię kierowania własną karierą):
ReplyDeletejako robotnik w fabryce prostych rowerów nie zarobię zbyt wiele.
Chociaż nie, bo w przemyśle produkującym towary masowe zadziała efekt skali. A w produkcji software... jak to było? "każdego specjalistę można zastąpić skończoną ilością studentów".
Produkując CRUDy nie tylko można, ale i powinno się. Tak więc pytanie w jakich klasach problemów chcemy się "pozycjonować".
@ToJaJarek
ReplyDeleteKłopot z metaforami jest taki, że pokazują one to, co chcemy, aby pokazały. Aby skonstruować dobrą metaforę, trzeba dokładnie zrozumieć poszczególne elementy rzeczywistości oraz relacje między nimi, a następnie przenieść je do innego uproszczonego kontekstu, który lepiej zobrazuje słuchaczowi w czym rzecz.
Ze swoją metaforą nieco przeholowałeś. Programista nie używający DDD korzysta ze "standardowych elementów", "śrubek" i to bardzo konkretnych.
Żeby nasza rozmowa chociaż ocierała się o merytoryczność trzeba by wystartować z w miarę uwspólnionej wiedzy o tym, co się dzieje w architekturze oprogramowania.
Na początek proponuję to: (w podanej kolejności)
* rozdział z Evansa o relacjach między bounded contextami
* http://www.infoq.com/presentations/ddd-eric-evans
* rozdział "From the Mud to Structure" z http://www.amazon.com/Pattern-Oriented-Software-Architecture-Distributed-Computing/dp/0470059028
* http://bottega.com.pl/pdf/materialy/receptury/ioc.pdf
* http://mbartyzel.blogspot.com/2008/06/strategie-decouplingu_12.html
* http://mbartyzel.blogspot.com/2010/10/kto-paci-za-dobry-kod.html
* http://mbartyzel.blogspot.com/2013/02/strategiczna-refaktoryzacja.html
Jeśli nie masz aż tyle czasu, to w wersji light zapraszam na http://2013.33degree.org/talk/show/73 lub do marcowego/kwietniowego numeru http://programistamag.pl
@Sławek
No właśnie szukam dobrej miary na "dostatecznie złożony lub skomplikowany"
W drugim, w kilku zdaniach poruszyłeś sporo tematów :) zbieram materiały do posta
@Sławek
ReplyDeleteZaktualizowałem, aby lepiej wyrazić intencję
@ToJaJarek
Zapomniałem o tym: http://laputan.org/mud/
ok, no to brniemy dalej:]
ReplyDelete"To prawdopodobnie dziedzina, którą informatycznie wspierasz nie jest zbyt złożonna"
Prawdopodobieństwo jest bliższe 0 czy 1?
Ale nie łapmy się za słówka... to nie jest kwestia prawdopodobieństwa. Dziedzina MA jakąś złożoność, nie ma tutaj co strzelać, trzeba ją określić o dobrać podejście.
Poza tym:
nie potrafię sobie wyobrazić jaki tok rozumowania (wraz z akrobacjami) może doprowadzić do takiej implikacji:
web AND baza => trywialna domena
Obalmy tę tezę metodą Reductio ad Absurdum zadając kolokwialne pytanie: a co ma niby być w warstwie prezentacji, urządzenie do nadawania danych alfabetem Morse'a podłączone na USB? Oraz drugie pytanie: a co ma niby być magazynem danych, wiaderka na qubity podłączone w RAID dajmy na to 5?
Chodzi mi o to: architektura systemowa i aplikacyjna to jeden aspekt, a dziedzina biznesowa to drugi aspekt - ortogonalny.
Jak pisze sam Vaughn Vernon: "DDD is not appropriate for just any enterprise application. Some applications can be more effectively developed using a tool or a framework that provides less modeling flexibility, but facilitates rapid development. This approach is especially applicable for very data-centric applications that require little thought about calculations, algorithms, and business processes. In such cases it makes sense to use a framework such as Ruby on Rails or Groovy and Grails, and just forget about crafting a true domain model."
ReplyDeleteWiec warto inwestowac w DDD tam gdzie mamy do czynienia z czyms wiecej niz przecietny CRUD :)
Polecam caly wywiad: http://www.informit.com/articles/article.aspx?p=2023702
@kris
ReplyDeleteTo jedna strona medalu. Drugą sprawą, moim zdaniem ważniejszą, są kompetencje ludzi. Na DDD rzucają się zespoły, które mają zbyt mało doświadczenia i umiejętności, aby to pociągnąć. Skutek jest zazwyczaj opłakany.