Katalog architektur, DDD, mikroserwisy, czysta i cebulowa architektura a także kilka słów wprowadzających do tematu, w tym czym jest architektura, jej poziomy, rola w dokumentowaniu rozwiązań i problemy przy próbach egzekwowania.
Bezstronność sądu i jej gwarancje w polskim procesie karnymepartnerzy.com
Bezstronność sądu i jej gwarancje w polskim procesie karnym - ebook
Autor: Wojciech Jasiński
Data wydania: 02.10.2009
Wydawca: Wolters Kluwer Polska
Stan prawny na 1.09.2009 r.
Zasadniczym celem niniejszej pracy jest rekonstrukcja znaczenia zasady bezstronności sądu. Zadanie to podejmowane jest z jednej strony na podstawie analizy polskiego porządku prawnego oraz dorobku orzecznictwa i doktryny. Z drugiej strony przedmiotem rozważań jest europejski standard bezstronności sądu kształtowany głównie w orzecznictwie Europejskiego Trybunału Praw Człowieka. Dla uzupełnienia i wzbogacenia powyższej perspektywy autor odwołuje się do doświadczeń państw systemu common law - Kanady i Stanów Zjednoczonych - w których problematyka bezstronności sądu ujmowana jest nieco odmiennie. W pracy poruszane są ponadto psychologiczne i etyczne aspekty bezstronności.
Drugi obszar refleksji stanowią gwarancje bezstronności sądu w polskim procesie karnym. Analizie poddane zostały zatem kwestie unormowania, funkcjonowania oraz optymalnego kształtu instytucji mających gwarantować bezstronność sądu.
Pełna wersja:
http://epartnerzy.com/e-ksiazki/bezstronnosc_sadu_i_jej_gwarancje_w_polskim_procesie_karnym___ebook_p12399.xml
Bezstronność sądu i jej gwarancje w polskim procesie karnymepartnerzy.com
Bezstronność sądu i jej gwarancje w polskim procesie karnym - ebook
Autor: Wojciech Jasiński
Data wydania: 02.10.2009
Wydawca: Wolters Kluwer Polska
Stan prawny na 1.09.2009 r.
Zasadniczym celem niniejszej pracy jest rekonstrukcja znaczenia zasady bezstronności sądu. Zadanie to podejmowane jest z jednej strony na podstawie analizy polskiego porządku prawnego oraz dorobku orzecznictwa i doktryny. Z drugiej strony przedmiotem rozważań jest europejski standard bezstronności sądu kształtowany głównie w orzecznictwie Europejskiego Trybunału Praw Człowieka. Dla uzupełnienia i wzbogacenia powyższej perspektywy autor odwołuje się do doświadczeń państw systemu common law - Kanady i Stanów Zjednoczonych - w których problematyka bezstronności sądu ujmowana jest nieco odmiennie. W pracy poruszane są ponadto psychologiczne i etyczne aspekty bezstronności.
Drugi obszar refleksji stanowią gwarancje bezstronności sądu w polskim procesie karnym. Analizie poddane zostały zatem kwestie unormowania, funkcjonowania oraz optymalnego kształtu instytucji mających gwarantować bezstronność sądu.
Pełna wersja:
http://epartnerzy.com/e-ksiazki/bezstronnosc_sadu_i_jej_gwarancje_w_polskim_procesie_karnym___ebook_p12399.xml
Psychologia Wywierania Wpływu I PsychomanipulacjiAdam
W jaki sposób skutecznie wpływać na innych i bronić się przed negatywnym wpływem z ich strony. Poznaj metody rozpoznawania kto jakim jest człowiekiem...
Prezentacja przedstawiona przez Stefan Kawalec, Adam Szyszka i Marek Góra podczas 74 Seminarium BRE-CASE: Problem of Pension Funds' Foreign Investment ( 23.09.2004 )
Zobacz więcej na nasze stronie: http://www.case-research.eu/en/node/56374
Podręcznik kreowania udanych przestrzeni publicznych
Najlepszy podręcznik na świecie dla tych, którzy chcą coś zmienić wokół siebie.
Jak przetworzyć Miejsce. Podręcznik kreowania udanych przestrzeni publicznych to tłumaczenie książki How to Turn a Place Around wydanej przez Project for Public Spaces, tłumaczenie na język polski: T. Jeleński, W. Kosiński.
Publikacja udostępniona dzięki uprzejmości Międzynarodowego Centrum Kształcenia PK i Fundacji Partnerstwo dla Środowiska, w ramach współpracy w sieci "Wspólna Przestrzeń"
PARP - Raport z badania Global Entrepreneurship Monitor – Polska
Tegoroczny Raport Global Entrepreneurship Monitor – Polska 2012 przedstawia obraz stanu przedsiębiorczości w Polsce na
tle innych krajów europejskich i Stanów Zjednoczonych w 2012 roku, jak i w zestawieniu z rokiem poprzednim. Opisuje intencje
i motywacje Polaków do zakładania działalności gospodarczej i jej rozwoju. Przedstawia także uwarunkowania przedsiębiorczości
w takich aspektach jak np. programy wsparcia dla rozwoju przedsiębiorczości, finansowanie działalności gospodarczej, transfer
technologii, uwarunkowania kulturowe i społeczne czy przedsiębiorczość kobiet oraz młodych osób.
Ciekawym wątkiem, któremu poświęcony został osobny rozdział w Raporcie są relacje biznesowe, gdzie przyjrzeliśmy się współpracy
zarówno przedsiębiorców we wczesnej fazie rozwoju, jak i dojrzałych podmiotów w zakresie bieżącego funkcjonowania
oraz działalności innowacyjnej. Analizowaliśmy ten temat również ze względu na wiek czy płeć przedsiębiorcy.
Zarówno wnioski dotyczące relacji biznesowych, jak i pozostałe dane z Raportu dotyczące stanu przedsiębiorczości czy uwarunkowań
jej rozwoju dostarczają wielu cennych informacji dla zrozumienia potrzeb obecnych i przyszłych przedsiębiorców. Dzięki
tej wiedzy możliwe jest tworzenie polityki przedsiębiorczości, stanowiącej odpowiedź na konkretne wyzwania.
Psychologia Wywierania Wpływu I PsychomanipulacjiAdam
W jaki sposób skutecznie wpływać na innych i bronić się przed negatywnym wpływem z ich strony. Poznaj metody rozpoznawania kto jakim jest człowiekiem...
Prezentacja przedstawiona przez Stefan Kawalec, Adam Szyszka i Marek Góra podczas 74 Seminarium BRE-CASE: Problem of Pension Funds' Foreign Investment ( 23.09.2004 )
Zobacz więcej na nasze stronie: http://www.case-research.eu/en/node/56374
Podręcznik kreowania udanych przestrzeni publicznych
Najlepszy podręcznik na świecie dla tych, którzy chcą coś zmienić wokół siebie.
Jak przetworzyć Miejsce. Podręcznik kreowania udanych przestrzeni publicznych to tłumaczenie książki How to Turn a Place Around wydanej przez Project for Public Spaces, tłumaczenie na język polski: T. Jeleński, W. Kosiński.
Publikacja udostępniona dzięki uprzejmości Międzynarodowego Centrum Kształcenia PK i Fundacji Partnerstwo dla Środowiska, w ramach współpracy w sieci "Wspólna Przestrzeń"
PARP - Raport z badania Global Entrepreneurship Monitor – Polska
Tegoroczny Raport Global Entrepreneurship Monitor – Polska 2012 przedstawia obraz stanu przedsiębiorczości w Polsce na
tle innych krajów europejskich i Stanów Zjednoczonych w 2012 roku, jak i w zestawieniu z rokiem poprzednim. Opisuje intencje
i motywacje Polaków do zakładania działalności gospodarczej i jej rozwoju. Przedstawia także uwarunkowania przedsiębiorczości
w takich aspektach jak np. programy wsparcia dla rozwoju przedsiębiorczości, finansowanie działalności gospodarczej, transfer
technologii, uwarunkowania kulturowe i społeczne czy przedsiębiorczość kobiet oraz młodych osób.
Ciekawym wątkiem, któremu poświęcony został osobny rozdział w Raporcie są relacje biznesowe, gdzie przyjrzeliśmy się współpracy
zarówno przedsiębiorców we wczesnej fazie rozwoju, jak i dojrzałych podmiotów w zakresie bieżącego funkcjonowania
oraz działalności innowacyjnej. Analizowaliśmy ten temat również ze względu na wiek czy płeć przedsiębiorcy.
Zarówno wnioski dotyczące relacji biznesowych, jak i pozostałe dane z Raportu dotyczące stanu przedsiębiorczości czy uwarunkowań
jej rozwoju dostarczają wielu cennych informacji dla zrozumienia potrzeb obecnych i przyszłych przedsiębiorców. Dzięki
tej wiedzy możliwe jest tworzenie polityki przedsiębiorczości, stanowiącej odpowiedź na konkretne wyzwania.
Pasja ukryta w pikselach
Obudź w sobie prawdziwego Łowcę Ujęć
Od czasu pojawienia się niedrogich aparatów cyfrowych liczba fotoamatorów nad Wisłą gwałtownie wzrosła, choć daleko nam jeszcze do japońskiego foto-szału. Większość posiadaczy "cyfrówek" zadowala się jednak obsługą przycisku migawki podczas rodzinnych imprez i wakacji. Na szczęście istnieją również prawdziwi pasjonaci — tacy jak Ty — którzy chcą, aby ich zdjęcia wyróżniały się ze stosów nudnych fotek, zapełniających albumy w każdym niemal domu.
Jeśli czujesz, że drzemie w Tobie świetny fotograf, który potrzebuje tylko kilku praktycznych rad, by poprawić swój warsztat, rozwinąć umiejętności, zdobyć zestaw przydatnych technik i dowiedzieć się, jak wykorzystywać wszelkie dostępne opcje posiadanego aparatu, ta książka z pewnością spełni Twoje oczekiwania.
Jeśli tylko masz wybór, pamiętaj — jakość, a nie jakoś.
Dlaczego warto wiedzieć?
Fotografowanie uczy patrzenia, pobudza wrażliwość i daje ogromną satysfakcję. Skoro masz w sobie pasję i talent, koniecznie trzeba je oszlifować.
* Dobór odpowiedniego dla Ciebie aparatu cyfrowego.
* Sztuczki i praktyczne porady na temat fotografowania.
* Zasady kompozycji wykonywanych zdjęć.
* Lifting zdjęć za pomocą programów komputerowych.
* Wykonywanie odbitek Twoich fotografii cyfrowych.
raport Global Entrepreneurship Monitor – PolskaOpen Concept
Polska Agnecja Rozwoju i Przedsiębiorczości przygotowała czwartą edycję raportu Global Entrepreneurship Monitor – Polska. Przedstawia w nim obraz przedsiębiorczości w naszym kraju na tle UE i świata. Obok głównych wskaźników opisujących postawy, aspiracje i zachowania przedsiębiorcze Polaków, raport zawiera dane nt. intraprzedsiębiorczości, przedsiębiorczości młodych oraz wyniki analizy za lata 2012-2014.
Raport w polskiej i angielskiej wersji językowej dostępny jest na stronie projektu pod adresem: https://badania.parp.gov.pl/global-entrepreneurship-monitor-gem
Źródło: www.parp.gov.pl
Ile zarabia kierowca zawodowy w Polskich firmach? Od czego zależy wysokość wynagrodzeń? Czy kierowca lubi swoją pracę? To i wiele więcej w Raporcie TransJobs.eu
Noc informatyka - co ja wiem o testowaniuTomek Borek
An old preso (in Polish) from May 2013 about testing and TDD for the beginner's crowd. Stara prezentacja z maja 2013 o testowaniu i TDD dla początkujących.
Quite often "new" people are only "new" to Postgres. This is my summary of do's and don'ts when it comes to teaching Postgres, what to take note on, with emphasis on teaching
This document discusses various tools for diagnosing performance problems in Java applications running on Linux. It introduces the concept of "The Box" which represents all of the components that can affect application performance, including traffic, code, JVM, OS, virtualization, and hardware. It emphasizes the importance of understanding how the application is used, its code and algorithms, JVM configuration and garbage collection, OS limits and configuration, and underlying hardware. It also recommends using tools like Linux perf and following Brendan Gregg's USE method of analyzing utilization, saturation, and errors of key resources to help identify bottlenecks. The key takeaway is that GNU/Linux has tools that can help determine what is impacting performance at each level from traffic
When performance hits rock-bottom everybody (and their dog) is called upon and all of a sudden developers should have been responsible for last half a year or so and code with performance in mind (and deadlines, but that of course goes unsaid). So, here I'm talking about what can a dev do to meet those unreasonable demands) and what might he do anticipating them.
Strictly JVM, mostly Sun Hotspot impl, but number of points can be used to other JVMs as wel
Java Memory Consistency Model - concepts and contextTomek Borek
Java Memory Consistency Model is a difficult topic.
It's useful in making sure that multi-threaded programs on multi-threaded cores will interact with each other (and through memory) in a consistent manner.
It's specification is damn hard (even according to folks with lots of concurrent experience, like Doug Lea) to read, understand and routinely follow without error.
This presentation talks about some fallacies surrounding memory model, explains it, offers definitions and reasons for it's existence. It ain't deep, it's more entry level stuff.
This document discusses advice for dealing with "fires" or urgent performance issues based on the author's experience as a consultant. The key points are:
1. Analyze issues using "the box" model to consider potential causes at different levels from the network to the application code.
2. Stay calm and collected when dealing with fires rather than losing your head or getting frightened. Make sure to double check your own work before others can blame you.
3. Set up monitoring tools and logging to get advance warnings of potential problems and gather the right diagnostic information when issues do occur.
4. Know when to remove yourself from a situation if there is too much ongoing stress from attempting to address fires. Your
Spróbujmy szczęścia bo zaciskanie pięści nie działaTomek Borek
Szereg studiów dotyczących szczęścia i kontroli pokazuje ciekawe rezultaty. Szczęście to mieszanina genetyki, czynników zewnętrznych i naszych czynów, myśli i nastawienia. Kontrola może być biologicznie wbudowaną potrzebą. Jedno i drugie zatem można zastosować w pracy i na pewno nie raz to już robiliśmy. Spróbujmy dowiedzieć się więcej, by wiedzieć gdzie i kiedy.
Lightning talk on Java Memory Consistency Model Java Day Kiev 2014Tomek Borek
Brief introduction into what Memory Model is about and why it matters and when. Explanation why it was changed in Tiger and how. Also informs where to look for more and offers definition. I've gave this talk at PJUG and Java Day Kiev in 2014.
Few words about happiness (Polish talk) / O szczęściu słów kilkaTomek Borek
Since latest One Beer Talks were rather on the hard side, I went with soft presentation and talked about happiness. I outlined new research and showed what was found and how and provided links for more. It's a short preso, a lightning talk if you will.
Ponieważ ostatne Piwne Gadki były raczej mocno techniczne, zrobiłem miękką prezentację o szczęściu, zarysowującą nowe badania nad nim i dającą ogólny pogląd o kilku rzeczach w tej domenie, wszystko w kwadrans.
It's not always the application's faultTomek Borek
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive function. Exercise causes chemical changes in the brain that may help protect against mental illness and improve symptoms for those who already suffer from conditions like anxiety and depression.
Talk in Polish, I and Jacek Jagieła gave at Polish JUG during JavaCamp #12. We presented what we believed would be good to know to design infrastructure fit for given purpose. Virtualization, network topology, monitoring, etc. Of course, since talk lasted one hour, in-depth approach wasn't possible. ;-)
Wprowadzenie do optymalizacji wielokryterialnej / Intro to multicriteria opti...Tomek Borek
Stara prezentacja moja i Karola opublikowana przez Alicję Pachocki, z czasów studiów.
http://slideplayer.pl/slide/60910/
Old preso done during my studies, introducing multicriteria optimization. Thanks to Alicja Pachocki for digging it out:
http://slideplayer.pl/slide/60910/
Git not for beginners. Confitura talk, in Polish. Describes detached head, commit, repository, SHA1, various ways of ignoring files, interactivity and more.
This document discusses and evaluates several architecture visualization tools. It notes that while all the tools have great conceptual mappings, some are more usable than others. Specifically, the SonarQube TreeMap plugin and Structure101 are highlighted as having intuitive mappings but also some constraints or limitations. Overall, the document concludes that no single tool is easy or usable enough on its own.
"Narco" emotions - description of study on whether Twitter can be used to gle...Tomek Borek
for UA class, we had to choose a HCI paper, read it and make a short presentation about it. Paper selection criteria was that it can be used to demonstrate how cognitive science helps UA. I kinda failed in that regard (there were much better papers out there) but the content of that paper hijacked my attention totally.
5. Przebieżka po nowoczesnych (i nieco starszych) architekturach, celem ich
przybliżenia raczej niż zgłębienia.
Organizacyjne sprawy
Przerwy - jak chcecie
Tempo - jak chcecie
Pytania - też jak chcecie
O mnie
Dzisiaj
Nie dogłębnie ile raczej płytko o innych i znacznie rzadszych niż trójwarstwówka podejściach do
archi.
Chciałbym:
!
1
6.
Przybliżyć Wam DDD
1. powiedzieć o wszechobecnym języku
2. o podstawowych klockach tego podejścia
3. o wzorcach w budowie tego
4. wyjaśnić czemu to moje ulubione podejście
!
Ostrzec Was przed modą, obecnie na µserwisy (wcześniej na SOA)
1. powiedzieć co to to SOA
2. i µserwis
3. przybliżyć zalety
4. pokazać wady, które nagminnie się pomija
!
Przypomnieć starsze, lecz ciekawe koncepty
1. Czystej architektury Wujka Boba
2. Cebuli
3. Portów i adapterów, tudzież heksagonu
Pytania?
2
7. Sprawdźmy poziom!
Łapki w górę kto…
1. potrafi rozwinąć SOLIDa?
2. a GRASPa?
3. potrafi wymienić inne niż z programu znane podejścia?
4. potrafi opowiedzieć o podejściach z programu?
5. przeczytał książki:
!
tzw. niebieską?
3
15. Koncepty: udziałowców, perspektyw, widoków
Zagrajmy
Pierwsze skojarzenie z architekturą?
Krzyczcie!
Wprowadzenie
Pięć poziomów architektury
• Architektura kodu (klasy)
• Architektura aplikacji (komponenty)
• Architektura systemu (rozwiązania - kontenery)
• Architektura wdrożenia (infra)
11
16. • Architektura korporacyjna (organizacji)
Architektura kodu
Poprzez definiowanie struktury, wzorce projektowe pomagają programiście
skupić się przede wszystkim na dziedzinie, na tym co system ma robić dla
użytkownika
Wzorce projektowe
Wzorce odnoszą się do
• Odpowiedzialności - pojedyncza
• Hermetyzacji - dokładamy a nie modyfikujemy
• Inwazyjności zmian
Clean code
Czysty kod jest prosty i bezpośredni. Czysty kod czyta się jak dobrze napisaną
prozę. Czysty kod nigdy nie zaciemnia zamiarów projektanta; jest pełen
trafnych abstrakcji i prostych ścieżek sterowania
— Grady Booch - Software Archeologist - IBM
SOLIDny programista
• S ingle Responsibility Principle
klasa powinna mieć tylko jeden powód do zmiany
• O pen Closed Principle
klasę można łatwo rozszerzać, nie modyfikując jej
• L iskov Substitution Principle
potomkowie to przeźroczyste zamienniki przodków
• I nterface Segregation Principle
dla różnych klientów twórz osobne interfejsy
• D ependency Inversion Principle
zależ od abstrakcji a nie od konkretnych implementacji
12
17. Wartości
• Kod jest podstawowym medium komunikacji w projekcie
• Jako zespół jesteśmy jednością
• Programy są częściej czytane niż pisane
• Więcej czasu poświęcamy na modyfikację istniejącego kodu niż na tworzenie nowego
Implementation patterns
• Komunikacja
kod źródłowy powinno się czytać jak książkę
• Prostota
wprowadzaj złożoność tylko kiedy jest to konieczne
• Elastyczność
to dodatkowa złożoność, więc wprowadzaj ją tylko tam gdzie to konieczne
Implementation patterns
• Lokalne konsekwencje
zmiana w jednym miejscu nie powoduje zmian w innych
• Dane i logika razem
ponieważ zmieniają się w tym samym czasie
• Symetria
utrzymuj podobny poziom abstrakcji
Egzekwowanie "architektury"
• W jaki sposób egzekwować architekturę?
• Code Review? Architecture Review?
• SonarQube? Metrics?
• Automated test suites? Chaos Monkey?
Warstwy
13
18. 4+1
• Nie ma pojedynczego spojrzenia na aplikację
• Każda aplikacja (system) ma kilku interesariuszy i każdy patrzy na system w inny sposób
• Użytkownicy
• Programiści
• Project Managerowie
• Inne widoki (views) są używane do przedstawienia innych perspektyw na system (viewpoints)
4+1
14
19. EA - definicja
Zbiór właściwości danej organizacji (korporacji) które stanowią o jej
możliwości realizacji celów
— własna parafraza Wikipedii
EA - frameworki
• TOGAF - The Open Group Architecture Framework
• ArchiMate
Pojmowanie architektury
• "Architektura" starzeje się bardzo szybko
• "Odcinamy się" w złym momencie
• Too much design in the architecture
• Architektura - wyznacza kierunek
• Projekt - szczegóły opisu
• Czy to właśnie nie doprowadziło nas do wielu problemów
• Astronauts' Architecture - artykuł Joel Spolsky
15
20. Problemy z projektowaniem
• Opis architektury starzeje się
• Nie nadąża za kodem, staje się bezużyteczny
• Ma niewiele wspólnego z rzeczywistością
• Jak dużo (mało) architektury powinno być architekturze
• Bardzo łatwo jest wszystko nazwać "architekturą"
• Przypadki użycia, sekwencje, WSDLe itd
!
16
22. Architektura jako strategia?
• Architektura powinna nam pomóc powiedzieć…
• Gdzie wprowadzić zmiany
• Dlaczego wprowadzić zmiany
• Wszystko inne jest projektem
• Jak implementować?
• Co zmieniać i kiedy?
Dokumentowanie decyzji
• Architektura to historia podjętych (albo nie) decyzji
• Decyzje mają:
• Tytuł
18
23. • Kontekst
• Decyzję
• Status (zaakceptowana, odrzucona)
• Konsekwencje
Michael Nygard - Documenting Architecture Decisions
DDD
Spis treści
• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Po co DDD?
• Dla większość projektów, najważniejsze jest zrozumienie logiku działania biznesu (domeny, logiki
domeny)
• Działania i operacje w domenie powinny być oparte o dobrze zdefiniowany model
Domain Driven Design
1. Sposób myślenia, według którego tworzona jest architektura systemu
2. Wszechobecny (ubiquitous) język dziedzinowy, w którym porozumiewają się interesariusze i
programiści
3. Odwzorowywanie w kodzie bytów i procesów biznesowych zarówno pod względem zachowania
jak i zachowania
4. Zestaw konceptów i procedur podstępowania do tego
Co to jest domena
• Domena to spójny podzbiór rzeczywistości biznesowej wraz obowiązującymi tam zasadami,
któremu można przypisać nazwę oraz jednoznaczną odpowiedzialność
• Finanse, kontroling
• Sterowanie ruchem sieciowym
• Domena wyłania się naturalnie, gdy trudno nam ogarnąć to, co robimy i trzeba spojrzeć na
19
24. problem z szerszej perspektywy
Izolacja domeny
• Domena przekłada się na spójną jednostkę oprogramowania
• Współpracujące domeny powinny być od siebie odizolowane za pomocą interfejsów
• Bounded contexts! (później)
Kiedy stosować?
• Domena jest złożona (nie wszystkie domeny mają charakter obiektowy)
• Zespół jest doświadczony w projektowaniu obiektowym
• Eksperci domenowi są stale dostępni
• Proces wytwarzania oprogramowania jest iteracyjny
Kontekst jest zawsze królem!
20
26. Kontekst
Bounded Context nie oznacza tylko enkapsulacji kodu lecz wyodrębnienie pewnego zagadnienia w
płaszczyznach:
• Architektonicznej
• Organizacyjnej
• Słownikowej
• Mentalnej
Relacje między kontekstami
• Wyodrębnienie kontekstów pozwala dostrzec relację między nimi
• Poszczególne relacje dają wskazówki dotyczące organizacji pracy nad systemem
Rodzaje relacji
• Continuous Integration
• Shared Kernel
• Customer / Supplier
• Conformist
• Anti-corruption Layer
• Separate Ways
• Open Host Service
Anti-corruption Layer
• Model chroniony jest warstwą abstrakcji, która amortyzuje zewnętrzne zmiany
• Kiedy stosować?
• System korzysta z kodu legacy
• System współpracuje z innymi systemami
!
22
27. Przykłady
* Wysokopoziomowe API na urządzenia sieciowe
* Odizolowanie kodu napisanego w C od nowego kodu tworzonego w C++
!
23
28. Spis treści
• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Ekspert domenowy
1. Dostępny
2. Rozumie ograniczenia
3. Rozumiany
4. Limit systemu!
Co mówi język?
@DomainService
public class BookKeeper {
public Invoice issue(Order order, TaxPolicy taxPolicy) {
//...
}
}
Co mówi model?
• fakturę wystawiamy na podstawie całego zamówienia
• nie ma możliwości wystawienia faktury na poszczególne pozycje
• nie ma możliwości wystawienia faktury zbiorczej na kilka zamówień
• możemy obliczać podatki dla dowolnego kraju, jest to domknięcie operacji issue, niezależne od
adresu klienta na zamówieniu
Skutki uboczne
Jako że model jest dokładnie oddany w kodzie, system działa tak jak rozumie to Ekspert Domenowy
• Ekspert rozumienie złożoności i kosztu zmian
• Cały zespół świadomie zaciąga dług techniczny i ogranicza punkty swobody modelu
• W powyższym przykładzie: nie możemy fakturować kilku zamówień ani poszczególnych
pozycji
24
29. !
Spis treści
• Po co Domain Driven Design?
• Ubiquitous language – komunikacja między programistami i ekspertami dziedzinowymi
• Bloki budujące w DDD i ich odpowiedzialności
Modelowanie z DDD
25
31. Kluczowe klocki
• Entity – identyfikowalne obiekty zawierające odpowiedzialność biznesową
• Aggregate – hermetyczne grafy obiektów, z jedną encją będącą "korzeniem agregatu", która
stanowi API całości. Agregat jest główną jednostką logiki domenowej w DDD
• Value Object – wrapper dla typów prostych, nadający im znaczenie biznesowe oraz wygodny
interfejs
Przykłady
• System ewidencji ludności – obiekt Adres jest encją, gdyż musi być unikatowy
• Wypożyczalnia książek – obiekt Adres nie jest encją, gdyż jest jedynie składową U
żytkownikaBiblioteki
27
32. • Student w kontekście finanse to zaledwie imię, nazwisko, nr albumu i konta.
• Student w ewidencji studentów to także listy przedmiotów i ocen (dużo kolumn i pól).
Value Object
• Grupuje dane należące do pewnej całości
• Nietrwały, nieunikatowy
• NumerTelefonu, KodPocztowy
• Pozwala nazwać konkretny byt z domeny
• Implementowany w oparciu o wzorzec Immutable
• Często używany w parametrach metod
Agregat i niezmienniki
• Zdania opisujące prawidłowości i reguły systemu
• Nie można dwa razy X
• Po każdej modyfikacji zawsze Y
• Jeżeli A wzrasta, to B maleje
!
28
34. Microservices are the new black
Monolithic vs Micro
Layers don’t matter anymore. Or, matter at much smaller scale.
!
Connections matter more though.
30
35. And how SOA fits?
So I get rid of complexity?
NO.
31
36. Monolithic TO micro then?
Tech and org transformational journey…
So! Microservices?
Micro Service is an architectural concept that aims to decouple a solution by
decomposing functionality into discrete services […] with communication over
lightweight mechanisms, often an HTTP resource API.
— Nick Nance and Jacob Madden
Summing up?
• Small business problem
• Independent and so deployed
• It’s own process
32
37. •
Integrates explicite through common interfaces
• While HTTP isn’t always the best answer, it’s a damn fine first guess
• Owns it’s data
Organization matters!
1. Conway’s law - you produce software organized as your company is
2. µservice won’t happen if you need to wait on shared teams (UX or - especially! - OPS)
!
!
Any organization that designs a system (defined broadly) will produce a design
whose structure is a copy of the organization’s communication structure.
— Conway's Law, Melvyn Conway
33
38. Cross-functional
When not to use?
1. Not good enough infra
2. No DevOps (or folks willing to become DevOps by baptism of fire)
3. Organizational constraints
4. Devs not aware of infra realities / distributed programming fallacies
Distributed Programming Fallacies
Keep in mind, that often programmers code, as if:
1. network was infallible
2. latency was zero
3. bandwith was infinite
4. and so on
!
Which obviously isn’t the case. Network and cabling are done by humans and thus flawed. They break.
34
39. There’s an excellent PDF in the matter, called Fallacies of Distributed Computing.
Tooling matters
http://www.slideshare.net/MarcinGrzejszczak/microservices-enough-with-theory-lets-do-some-code-
geecon-prague-2015
Note how many tools they have on the setup diagram.
Note how many they used and NOT mentioned on that diagram (second to last slide lists them all).
There are many tools involved and infrastructure cannot be neglected.
Traceable requests?
1. message-driven apps, asynchronous calls
2. plethora of services, how users go about the system?
3. Correlation ID helps in finding out
4. Correlate i.e. match; show the relationship
Request ID
1. Requestor → Request message (with assigned request ID
an identifier that is different from those for all other currently outstanding
requests, that is, requests that do not yet have replies.
— Enterprise Integration Patterns
Correlation ID
When the replier processes the request, it saves the request ID and adds that
ID to the reply as a correlation ID. When the requestor processes the reply, it
uses the correlation ID to know which request the reply is for. This is called a
Correlation Identifier because of the way the caller uses the identifier to
correlate each reply to the request that caused it.
— Enterprise Integration Patterns
35
40. Implications
1. Correlation id should be an element of Shared Components API
2. User’s request flow
3. Must be reproducible based on log files and the correlation id
How to?
Yan Cui explains it nicely!
Clean + Onion architecture
Założenia clean architecture
• Niezależność od frameworka
• architektura nie może zależeć od obecności (lub nie) któregoś frameworka. Biblioteki są
narzędziami a nie elementem rozwiązania
• Testowalność
• Reguły biznesowe muszą być testowalne bez UI, bazy danych, serwera aplikacyjnego lub
jakiekolwiek zewnętrznego elementu
!
• Niezależność od interfejsu użytkownika
• Interfejs użytkownika musi być łatwo wymienialny bez wpływu na resztę systemu. WWW na
CLI, bez wpływu na reguły biznesowe
• Niezależność od bazy danych
• Reguły biznesowe nie mogą być zależne od konkretnego silnika bazy danych: Oracla, SQL
Server, MongoDB czy Couchbase
Jak to wygląda?
36
41. Elementy architektury
• Encje
• Przypadki użycia
• Adaptery
• Frameworks and Drivers
Adaptery
• Warstwa pośrednia między sednem aplikacji i satelitami (jak UI czy BD)
• Transformują dane z formatu odpowiedniego dla przypadków użycia i encji na język bazy danych,
WWW.
• Co jest przekazywane do sedna aplikacji nie powinno zawierać elementów świata zewnętrznego
• SQL, ResultSet, MongoDB Collection, BSON, HttpSession, HttpRequest
High level view
37
45. Założenia Onion Architecture
• Aplikacja zbudowana jest dookoła niezależnego (od frameworku) modelu obiektowego
• Wewnętrzne warstwy definiują interfejsy, które zewnętrzne warstwy implementują
• Sprzęgnięcia są od zewnątrz do środka
• Zewnętrzne warstwy zależą od wewnętrznych, a nie odwrotnie
• Kod aplikacji (application core) może być kompilowany i uruchamiany niezależnie od
infrastruktury
Jak to wygląda?
41
46. Podsumowanie
Powtórzmy ciekawe rzeczy.
1. architektura jest czym innym dla każdego z nas
2. wiele sposobów na ujęcie jej w projekcie / systemie
DDD?
DDD stawia na eksperta domenowego, wszechobecny język i izolację domen (konteksty)
µserwisy?
Samodzielne małe programiki z dobrą inter-komunikacją i zautomatyzowaną infrastrukturą
Cebula i czysta architektura
Warstwowe podejście, uniemożliwiające wprowadzenie zewnętrznego kodu za głęboko w domenę.
Szybka możliwość podmiany komponentów.
42