Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA

Czy wiesz, że:

• Lazy Loading nie ma sensu
• Mapowanie @OneToMany z wykorzystaniem tabeli linkującej (domyślne zachowanie hibernate) nie ma sensu
• Blokowanie Optymistyczne oparte jedynie na @Version nie ma sensu

...jeżeli stosujesz zasady Object Orinted i JPA (lub inny maper relacyjno-obiektowy).


Jeżeli powyższe tezy targnęły Twoimi emocjami, to zapraszam do lektury najnowszego artykułu: Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA (do pobranie całkowicie free), który ukazał się w najnowszym numerze programistamag.pl (wakacyjny numer o podwójnej objętości dostępny w Empikach lub w formie elektrycznej).

Zapraszam do śledzenia całej serii Laboratorium Bottega - Receptury projektowe – niezbędnik początkującego architekta.

3 zasady optymalizacji

1. Nie optymalizuj - jeżeli na prawdę tego nie potrzebujesz - być może to "tylko" twoje ego chce się pobawić pozostając w strefie komfortu; spójrz na parking za oknem i policz ile samochodów tam stojących było projektowanych z myślą szybkości (chyba, że pracujesz w centrum Londynu:)
2. Nie optymalizuj jeżeli nie rozumiesz co robisz - być może dotkniesz warstw, gdzie nie sięgają Twoje kompetencje - i być może cały Twój wysiłek zostanie zniweczony na poziomie pakietów i ramek TCP/IP lub będzie pomijalny dzięki optymalizacjom wirtualnej maszyny
3. Nie optymalizuj jeżeli nie mierzysz wydajności przed i po - być może intuicja, która świetnie działa na sawannie, nie działa w świecie krzemu - i być może wysłanie kilku zapytań do bazy danych, obróbka wyników w pamięci serwera aplikacji jest lepszym pomysłem niż jedno zapytanie z 30 joinami:P

btw: pamiętaj, że wirtualna maszyna Javy "wie" o optymalizacji więcej niż znakomita większość programistów C - zwykle wystarczy się nie wydurniać, a JVM zajmie się resztą...

Twój mózg Cię oszukuje (gdy uczysz się nowego języka)

Dziś chciałbym polecić prezentację, którą powinien obejrzeć każdy programista: Don’t Trust Your Brain.
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)

W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.

//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...

Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne

"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.

Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?

W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:

• ODD, 
• podstawy podejścia funkcyjnego, 
• Building Blocks wchodzące w skład Domain Driven Design,
• architekturę na poziomie aplikacyjnym.

W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:

• stabilną - której kod relatywnie rzadko podlega zmianom
• domknięcia logiki - które nie polegają zmianom a rozbudowie
• wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)

Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...

Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje

C4 - Zwinne podejście do odkrywania i dokumentowania architektury

W jaki sposób dokumentować architekturę systemu - z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną?

Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział  gdzie 'włożyć ręce'".

Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".


/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).

**************************/

Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.

Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).


//===================================================

Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.

Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4:  mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).

Materiały z konferencji 33rd Degree

Oto obiecane materiały:

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego - problemy, strategie, taktyki, techniki i narzędzia






Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się w ciągu 6 lat stosowania i nauczania DDD






Dodatkowo dla osób, które pytały o inne prezentacje:

Architektura Ports & Adapters
Wstęp do DDD: Domain Driven Design - A place for everything and everything in its place
Architektura CqRS: Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw

Projekt referencyjny: DDD & CqRS Sample Leaven


//==========================

Jak zwykle feedback odnośnie prezentacji mile widziany - może być na prv.

Mock czy Stub? Command-query Separation prawdę ci powie.

Testując jednostkowo sieć powiązanych obiektów, dążymy do ich testowania w separacji. Separację osiągamy dzięki stosowaniu różnego rodzaju „dublerów”.

Często bez zastanowienia stosujemy dublery typu Mock. Mocki są relatywnie pracochłonną techniką, która nie zawsze jest uzasadniona - czasem wystarczający jest Stub (Fowler o różnicy pomiędzy Mock a Stub: Mocks Aren't Stubs).


W najnowszym wydaniu programistamag.pl opublikowałem artykuł zatytułowany "Mock czy Stub? Command-query Separa-tion prawdę ci powie." przedstawiający pragmatyczną „reguła kciuka” oparta o paradygmat Command-query Separation, która daje prostą odpowiedź co do typu dublera, jakiego potrzebujemy w teście jednostkowym.

Artykuł tradycyjnie do pobranie (całkowicie darmowo) tutaj: http://www.bottega.com.pl/artykuly-i-prezentacje.

//=======================================

Dla niecierpliwych esencja reguły:

• metody typu query -> użyj Stub
• metody typu command -> użyj Mock