piątek, 11 lipca 2008

Dysonans kognitywny

Normalny zdrowy i niewytrenowany umysł ma nie lada problem z jednoczesnym utrzymaniem się przy 2 ortogonalnych ideach. Nazywa się to dysonansem kognitywnym. Umysł ma tendencję do dorabiania sobie teorii i mitów aby tylko usprawiedliwić lenistwo intelektualne i trzymanie się tego co znane - wszystko w celu minimalizowania dysonansu. Wbudowane mechanizmy obronne chronią mózg przed przegrzaniem wybierając ideę bardziej znaną a inne odrzucając jako z gruntu złe.

Osobniki unikające myślenia krytycznego (myślenia nad tym co się myśli) mają łatwiej - są w stanie bez skrupułów odrzucić niewygodny pogląd i przy okazji stwierdzić, że osoba go głosząca "nie zna sie, jest gupia i filozuje". Wszyscy inni aby doraźnie zdusić to dręczące i nieprzyjemne uczucie napięcia psychicznego towarzyszące dysonansowi uciekają się do trików typu wysiłek fizyczny lub upojenie alkoholowe;)

Magicy od NLP zalecają strategię pytań w celu przebicia się przez mur uprzedzeń. Twierdzą oni, że nie da się kogoś przekonać do innych poglądów jedynie próbując je artykułować. Natrafiamy wówczas na opór wywołany dysonansem kognitywnym, który spowoduje jedynie mocniejsze utwierdzenia w przekonaniach - pomóc tu mogą jedynie elektrowstrząsy;)
Zamiast tego lepiej jest wczuć się w rolę osobnika którego chcemy przekonać, zacząć mówić jego językiem a później zacząć zadawać pytania. Pytania mają ogromną siłę zdolną rozbić mur uprzedzeń. Siła ta polega tym, że na pytanie zawsze zostanie udzielona odpowiedź - nie koniecznie jawnie, ale przynajmniej w środku, w Czesiu.


W poprzednim poście zachwalałem książkę, która wywarła ogromy wpływ na moje rozumienie procesu powstawania oprogramowania i myślenie o poziomach abstrakcji. Niedawno zainspirowany gorącą dyskusją o DDD na forum Springa i z polecania Rafała Barszczewskiego zacząłem czytać "Domain-Driven Design: Tackling Complexity in the Heart of Software" Erica Evansa.

Co prawda przeczytałem dopiero pierwszą (z 4) część ale już widzę, że zapowiada się dzieło na miarę Larmana. Evans dzieli się głębokimi i trafiającymi w sedno przemyśleniami o przyczynach niepowodzeń projektów (nawet tych, które w pierwszym roku wyglądały na wspaniały sukces), sięga do natury developerów i opisuje ich błędy od strony psychologicznej.

Póki co z lektury pierwszej części Okazuje się, że należy jednak utrzymywać jeden model łącząc poziom analizy i projektu - inaczej niż u Larmana.

Do nasilenia mojego osobistego dysonansu przyczynia się również praca nad architekturą nowego systemu. Z jednej strony chciało by się zaprojektować go inaczej niż do tej pory, uniknąć pułapek i bałaganu do którego w sposób nieunikniony prowadzą dotychczasowe doświadczenia. Może zastosować podejście Evansa... Z drugiej strony wymagania niefunkcjonalne takie jak integracja ze starymi systemami czy modularyzacja posunięta do granic absurdu uniemożliwiająca wypracowanie eleganckiej i prostej architektury - po prostu nakładanie gaci przez głowę.

Mało tego... okazuje się, że wspaniałe frameworki niezbyt wspierają DDD. Raczej anemiczny model domenowy. Springowcy coś ściemniają. Seam to wogóle szczyt prostactwa architektonicznego. Hibernate - diabeł tkwi w szczegółach i rozwala OO:/

Co więcej... potwierdzają się odczucia mojej kobiecej intuicji iż lansowana dotychczas architektura (czy to Springowa czy EJB) to po prostu proceduralne badziewie. Może to okaże się jakąś namiastką: Real Object Oriented.

Zachęcam do dyskusji... Czy macie jakieś doświadczenia z Domain Driven Deveopment? A może ktoś zechciałby podzielić się nimi w formie prezentacji na JUG?

//==============
W najbliższym czasie obiecuję recenzję książki Evansa. W nieco dalszej przyszłości spróbuję opublikować wyniki pracy nad opracowywaną architekturą.

5km biegu nie pomogło; może jutro low-level format w sprzyjających okolicznościach przyrody jeziora...

6 komentarzy:

Przemek pisze...

"Springowcy coś ściemniają. Seam to wogóle szczyt prostactwa architektonicznego. "

czy nastąpił update poglądów ?

Sławek Sobótka pisze...

Może nie tyle update, co krystalizacja.

O ile pamięta, to w 2009 - kiedy powstał post sytuacja wyglądała następująco:
- Springowcy skupili się na wstrzykiwaniu Repo do Agregatów (no i przezwali sobie DAO na Repo)
- W Seam ja to w Seam... narzędzie potężne, ale wszelkie przykłady były wówczas kreowane w stylu: jedna warstwa jest lepsza niż trzy. A DDD... co to w ogóle jest DDD.

Aktualnie w Seam niewiele się zmieniło. W sensie myślenia twórców przykładów - bo nic nie stoi na przeszkodzie aby użyć tego ficzer-worka w sposób taki jak chcemy.

Przemek pisze...

Może pokusisz się wiec o prosty przykład DDD w seam ? Może już nie w tym temacie tylko w turbo-seam...

btw: Czy DAN ALLEN w książce "Seam in Action" należy do grona tych twórców

Sławek Sobótka pisze...

Książka Dana jest generalnie bardzo dobra pod względem podejścia do arcytrudnego problemu pod tytułem: pokazanie czegoś tak rozległego merytorycznie jak Seam.
Wg mnie jest to najlepsza książka o Seam - ale pod warunkiem, że ktoś zna już JPA i JSF.

Natomiast przykłady modelowania w niej są banalne - bo takie chyba miały być aby móc skupić się na technikaliach.
O ile pamiętam to architektura jest również bardzo prosta - raczej wszystko do jednego worka, bez warstw... mamy ew. gdzieś delegację do jakiegoś serwisu.
O ile tez pamiętam to pojawia się w stępie preaching, że oto wreszcie nie musimy tworzyć tylu warstw hehe. Ale może też coś pomyliłem z innymi książkami o Seam. Już nie pamiętam jak to było u Dana...

Co do przykładu, to jest z nim dużo roboty, ale jak znajdę czas to dodam go do listy turbo-seam.

Przemek pisze...

Nie pomyliłeś się. Nagle okazuje się ze "cudownie" z trzech warstw robią się nam dwie bo widok operuje bezpośrednio na encjach.

Stad też chciałbym zobaczyć jakiś przekrojowy przykład w stylu DDD który jednak wydaje się koncepcją 180st inna aniżeli proponowana przez seam-gen ( a to juz nie są ksiązkowe przykłady )

Sławek Sobótka pisze...

Jam bym powiedział, że nie dwie a jedna, bo co robi akcja:
- logika biznesowa i logika aplikacyjna
- sterowanie zmianą widoku
- logika widoku: atrybuty dla rendered, FacesMassages,...
- logika dostepu do danych - składanie zapytan (bo nie zawsze named query wystarczy)

Tak wiec tam siedzi wszystko... xhtml jest tylko szablonem widoku, ale czasem potrzeba nieco logiki rysowania.

Generator do eclipsa robi jeszcze lepiej... wszystko siedzi sobie radosnie w stanowym ejb:)

Zgodnie z hinduską filozofią programowania "because we can";)