W tym wszystkim brakuje mi jednej rzeczy, bez której refaktoryzacja przypomina szalony bieg z tasakiem. Refaktoryzacja do czego? Nie do wzorców, nie do SOLID, nie do Clean Code...
Do postaci, która oddaje zrozumienie problemy (dziedziny). Z moich obserwacji tego właśnie brakuje, ten i problem w pewnych klasach systemów próbuje rozwiązać DDD.
(...)
Zacząłem odpisywać i się rozpisałem, wiec przerzucam do posta.
A wiecie, że w systemach a'la Oracle Forms, bez obiektowej warstwy aplikacyjnej, rzadko występują problemy właściwe systemom, w których się tę warstwę wepchnęło? Z pewnością widziałem mniej systemów niż niektórzy z czytelników, trochę jednak widziałem, i takich i takich.
Nie trzeba zastanawiać się nad rozszerzalną (czy to cokolwiek sensownego znaczy?) architekturą, bo architektura jest mocno narzucona; nie trzeba kombinować jak uzyskać możliwość szybkiego wdrażania, bo mamy to prawie out of the box.
Programiści PL/SQL raczej nie narzekają na jakość kodu, wydajność, złożoność przypadkową i intencjonalną. Radzą sobie. Czasem nawet dziwią się, że w OO-świecie są tego typu problemy. Już słyszę obiekcje, że OOP nadaje się do dużych systemów. Akurat te największe, z którymi miałem do czynienia, były db-centric.
Być może ludzie wymyślili DDD, frameworki (sygnalizowałem to wcześniej) inne takie tam tylko po to, aby poradzić sobie z problemem, który sami wygenerowali wymyślając OOP. Po co więc brnąć w coś i rozwijać metody, skoro to coś samo w sobie zostało oparte na niewłaściwych (zbyt skomplikowanych) założeniach?
Dalej, logiczna prostota (i idące za tym ograniczenia) technologii typu Forms, sprawia że łatwiej skonkretyzować oczekiwania użytkowników. Dlaczego? Bo technologia z góry narzuca, co jest dozwolone, a co nie jest i nie pobudza fantazji zbyt wieloma opcjami do wyboru. Może i działa to nieco odwrotnie: oto już IT nie "modeluje" świata biznesu, lecz daje biznesowi parę formatek, nazwy pól, a biznes sobie projektuje co i jak ma działać.
Co właściwie, wymienione na początku DDD próbuje rozwiązać (mowa tu o tej części książki, w której mamy bloki budujące)? DDD chce stworzyć koncepty, dzięki którym będzie można łatwiej opisywać rzeczywistość i jednocześnie przekładać ten opis na model obiektowy. Trochę nadużywamy słowa "model". Model to model - opis działania rzeczywistości taki jak np. poniższy. Same prostokąciki, strzałki, napisy itd. Tak jak na rysunku.
Teraz ten model można przenieść do świata IT na wiele sposobów. Można za pomocą obiektów (co robi DDD), można przełożyć na związki encji, nawet na pliki - wszystko jedno. DDD to tylko narzędzie do przekładania modelu do IT w jakiś specyficzny sposób. DDD to tylko jedna możliwości. Czy aby na pewno OOP jest najprostszym sposobem na przenoszenie modelu do IT?
Prócz standardowego trójkąta projektu, zespół podlega jeszcze jednemu ograniczeniu: kompetencje programistów. Gdybyśmy w każdym zespole mieli samych Ericków Evansów, to w warstwę aplikacyjną, OOP, DDD można wchodzić w ciemno. Najczęściej jednak raz na jakiś czas zdarzy się jakiś "quasi-Evans", a większość to jednak Janowie Kowalscy.
Jakiś czas temu, 60-letni uczestnik szkolenia Wzorce Projektowe. Powiedział: "Nie bardzo rozumiem, po co te wszystkie klasy? Kiedyś to, co się pisało, trzeba było porządnie nazwać i to zazwyczaj rozwiązywało problemy" I o to chodzi: grunt to prostota.
Znowu z ostatniego akapitu wynika, że mówimy o tym samym, mając jedynie inne nazwy na problemy i podejścia do rozwiązań:)
ReplyDeleteNa początek trochę prostowania pojęć: w DDD nie chodzi o Object Oriented ani o Building Blocks. Są to jedynie techniki stworzone na potrzeby pewnego kontekstu. Można użyć sobie innych technik i innych BB (np z kontekstu formsów).
Co do książki Evansa trzeba ją czytać co pół roku poczynając od drugiej połowy:)
Co do tego, że ktoś nie narzeka, to różne mogą być tego przyczyny - np. to, że jest super, albo brak świadomości, że super nie jest:P
Odnośnie modelu... no więc właśnie, co to jest model? Jakie są rodzaje modeli? Czym różni się model od szkicu wizji, słownika rzeczowników i (jedynie) semantycznych relacji pomiędzy nimi. Jaką wartość ma sam diagram relacji encji? Na pewno lepiej go mieć niż nie mieć. Czy w systemie klasy "przeglądarka do bazy danych" z autystycznym UI, od którego nikt nie wymaga szybkich zmian dostosowujących biznes do walki z konkurencją potrzeba DDD? :PPP
Lepiej od strony praktycznej: do czego służy model? Kiedy i do czego go potrzebujemy oraz w jakiej formie a kiedy jest zbędny. Bez odpowiedzi na to pytanie wszyscy będziemy jedynie dokonywać projekcji swoich doświadczeń na zbyt szeroką ogólność.
Nie wierzę w to co przeczytałem.
ReplyDeleteKojarzy mi się z tym "po co te wszystkie klasy" taka historia, że kiedyś po wygłoszeniu wykładu o systemie, który automatyzował pewien proces, ktoś z sali zapytał mnie:
"po co automatyzować skoro równie dobrze może to zrobić człowiek"
Niby można odpowiedzieć: "żeby człowiek tego nie musiał robić", ale czasem po prostu ręce opadają.
W tym przypadku można byłoby polecić przejrzeć badania porównujące wyniki projektów pisanych w językach proceduralnych do tych pisanych w obiektowych, zamiast opierać się na własnych (niemierzalnych) doświadczeniach, ale po prostu ręce opadają.
Ciekawa interpretacja... problem z Oracle i Formsami (i nie tylko) polega na tym, że model relacyjny jako taki nie spełnia elementarnej zasady: "niezmienny ale rozszerzalny". Po co ona? No po to by możliwe było rozszerzanie dodawania kolejnych usług, "naprawianie" już istniejących bez zmiany struktury całego systemu. W metodach relacyjnych raz opracowany model relacyjny danych, opisujący jakąś firmę jest betonowym fundamentem aplikacji. Po drugie niestety model relacyjny to model stratny, zebranie danych z faktur, zamówień, kartotek itp. i znormalizowanie tego powoduje, że mamy uporządkowane dane ale już nie mamy biznesowych ich znaczeń i roli. Miasto w słowniku przestaje być miejscem ulokowania magazynu, itp.
ReplyDeleteWyobraźmy sobie, że mamy "out of the box" system, który zarządza od lat magazynem, struktura bazy przewiduje rekordy opisujące towar z polem ilość itp.. system pracuje kilka lat (ma dużo tych danych) i nagle pojawia się wymóg ustawowy: musimy zacząć operować wiedzą o każdym sprzedanym egzemplarzu (np. numer seryjny), rozbudowa dobrze zaprojektowanego, obiektowo zorientowanego systemu, będzie możliwa bez prucia całości, baza relacyjna będzie do przeróbki i migracji...
Owszem mało mamy programistów Evansow, tak samo jak mało mamy murarzu architektów i projektantów, jeżeli ktoś uważa, że to programista na "obmyślać implementację" to czyni błąd w założeniach...
Patryku, obawiam się, że masz rację...
@Sławek
ReplyDeleteWpadnę na http://2013.33degree.org/talk/show/24, bo chyba tam szerzej rozwijasz swoje stanowisko z komentarza.
@Patryk
"(...)można byłoby polecić przejrzeć badania porównujące wyniki projektów pisanych w językach proceduralnych do tych pisanych w obiektowych"
A mógłbyś przytoczyć konkretne badania, z którymi moglibyśmy się zapoznać?
@ToJaJarek
"problem z Oracle i Formsami (i nie tylko) polega na tym, że model relacyjny jako taki nie spełnia elementarnej zasady: "niezmienny ale rozszerzalny". Po co ona? No po to by możliwe było rozszerzanie dodawania kolejnych usług, "naprawianie" już istniejących bez zmiany struktury całego systemu. W metodach relacyjnych raz opracowany model relacyjny danych, opisujący jakąś firmę jest betonowym fundamentem aplikacji. Po drugie niestety model relacyjny to model stratny, zebranie danych z faktur, zamówień, kartotek itp. i znormalizowanie tego powoduje, że mamy uporządkowane dane ale już nie mamy biznesowych ich znaczeń i roli. Miasto w słowniku przestaje być miejscem ulokowania magazynu, itp"
Wnioskowanie ok. Tyle, że jest dedukcyjne. Bierzesz założenia i potencjalne konsekwencje jednego i drugiego podejścia i wnioskujesz o wyższości jednego nad drugim. Oprócz tego, że żadne z podejść nie jest lepsze "w ogóle" lecz w ściśle zdefiniowanym kontekście, trzeba zauważyć, że to wnioskowanie jest czysto teoretyczne. Czy doszedłbyś do tych samych wniosków, gdybyś zaczął analizować konkretne rozwiązania rzeczywistych zespołów stosujących oba podejścia, ich problemy i efekty?
"Wyobraźmy sobie, że mamy "out of the box" system, który zarządza od lat magazynem, struktura bazy przewiduje rekordy opisujące towar z polem ilość itp.. system pracuje kilka lat (ma dużo tych danych) i nagle pojawia się wymóg ustawowy: musimy zacząć operować wiedzą o każdym sprzedanym egzemplarzu (np. numer seryjny), rozbudowa dobrze zaprojektowanego, obiektowo zorientowanego systemu, będzie możliwa bez prucia całości, baza relacyjna będzie do przeróbki i migracji..."
Podobnie j.w. "będzie możliwa". W domyśle: teoretycznie. Jak wspomniałem we wpisie, opieram się tylko i wyłącznie na własnych spostrzeżeniach bez formułowania ogólnych idei, aczkolwiek zespoły pracujące z OO-warstwą aplikacji zazwyczaj mają problemy, które opisałeś. Doprowadzają do monolitycznej architektury, trudnej w rozbudowie, a bezmyślnie stosowane frameworki i *-Driven* jeszcze bardziej komplikują sprawę. W zespołach stosujących teoretycznie "gorsze i mniej elastyczne" podejścia, wspomnianych problemów jest mniej.
Nawet jeśli któreś z podejść ma lepsze założenia teoretyczne, to nie oznacza to, że efekty jego stosowania będą również lepsze. Tak jak wspomniałem we wpisie, ogromną barierą w zespołach są kompetencje. Niezwykle rzadko się wspomina, że do sensownego zastosowania OOP, DDD, itd, trzeba mieć naprawdę, ale to naprawdę świetny zespół ze sporym doświadczeniem. Dogmatyczne i bezkontekstowe stosowanie jakiegoś podejścia, bo jest najlepsze "w ogóle" zazwyczaj przynosi więcej szkody niż pożytku.
To wyjaśnienie wiele: "Tak jak wspomniałem we wpisie, ogromną barierą w zespołach są kompetencje."
ReplyDeleteJeżeli ktoś z góry zakłada, że projekt będą realizowali nieudacznicy faktycznie chyba musi zadowolić się metodami pracy dostosowanymi do tych kadr... żadne inne wytłumaczenie nie przychodzi mi do głowy...
@ToJaJarek
ReplyDeleteA ten wykres
http://pl.wikipedia.org/wiki/Rozk%C5%82ad_normalny
jest Ci znany? Jak mawia bohater z tej sceny http://www.youtube.com/watch?v=f5RsG2Oiw6k "mamusię oszukasz, tatusia oszukasz, ale życia nie oszukasz"