Warsztat ekspercki to coś więcej niż szkolenie. To praca w kontekście konkretnych problemów.
Tytuł: | Projektowanie microservisów z użyciem DDD |
Kod: | arch-ms-ddd |
Kategoria: | Microservices |
Forma: | 40% wykłady / 60% warsztaty |
Czas trwania: | 3 dni |
Odbiorcy: | analitycy, architekci, developerzy |
Zapisy: |
Indywidualne zamówienie i dopasowanie dla grupy. |
Logistyka: |
W siedzibie klienta lub w innym dowolnym miejscu. |
Warsztat jest przeznaczony dla uczestników, którzy zastanawiają się jak pogodzić zrozumienie dziedziny problemu z decyzjami technicznymi. Nieodpowiednie ustalenie granic, odpowiedzialności i hermetyzacji usług prowadzi w krótkim czasie do katastrofy całego systemu.
Mikrousługi zamiast pomagać i spełniać składane obietnice powodują dodatkowy narzut złożoności technicznej i chaos organizacyjny. Dzięki zastosowaniu strategicznych wzorców DDD oraz analizy Event Storming zorientowanej na zachowania i reguły jesteśmy w stanie racjonalnie podejść do wymienionych problemów i przygotować się na większość typowych sytuacji, które naruszają architekturę rozwiązania.
Warsztat prezentuje spójną metodykę, która integruje rzetelną analizę, sprawdzone style architektoniczne i najlepsze wzorce implementacyjne.
Poznaj ekspertów, którzy mogą poprowadzić Twój Warsztat.
Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.
Artykuł jest pierwszym z serii tekstów mających na celu szczegółowe przedstawienie kompletnego zestawu technik modelowania oraz nakreślenie kompletnej architektury aplikacji wspierającej DDD.
Artykuł poświęcony zaawansowanym technikom modelowania taktycznego (Building Blocks) oraz technikom strategicznym
Artykuł poświęcony szczegółom implementacyjnym DDD.
Artykuł poświęcony technikom implementacji stosu Write w architekturze CqRS
Artykuł poświęcony kompleksowym technikom testowania automatycznego systemu stworzonego zgodnie z DDD
Artykuł poświęcony technikom implementacji stosu Read w architekturze CqRS
Artykuł poświęcony metodyce modelowania DDD Modeling Whirlpool z elementami BDD i Specification by Example
Artykuł poświęcony technikom odwracania kontroli w ujęciu: problem, idea, motywacja, zastosowanie, technika, kiedy nie stosować.
Artykuł przedstawiający metodę doboru zaślepek (Mock/Stub) dla testów jednostkowych na podstawie paradygmatu CQS.
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ą.
Artykuł przedstawia meta-model, którym możemy posiłkować się w zmaganiach ze złożoną logiką biznesową. Meta-model będzie praktyczną realizacją drugiej zasady SOLID: Open/closed principle, która pozwala tworzyć rozwiązania otwarte na rozbudowę (rozbudowa to nie to samo co zmiana).
Stosując mapery relacyjno-obiektowe, zwykle nie zastanawiamy się nad problemami związanymi z niespójnością danych wynikającą ze stosowania Lazy Loadingu, granicą spójności obiektów podczas zapisu kaskadowego oraz pułapkami naiwnego blokowania optymistycznego.
Artykuł przedstawia koncepcję Wzorców analitycznych – adresujących rozwiązania na poziomie analizy systemowej. Ilustracją na przykładów jest kilka wybranych, w tym najbardziej popularnym z nich: Party – będą one również alternatywą dla typowych naiwnych książkowych modeli struktur organizacyjnych.
Wiele czasu i energii spędzamy na dyskusjach o wyższości jednego paradygmatu programowania nad innym, o wyższości jednego języka programowania nad innym. W niniejszym artykule chcę przekonać czytelników do tego, aby obok siebie, równorzędnie stosować zarówno paradygmat obiektowy, jak i funkcyjny oraz nie zapominać o proceduralnym.
Do czego może przydać mi się propagacja transakcji inna niż REQUIRED? Jak zachowa się wówczas EnityManager i cache pierwszego poziomu? Jak uniknąć zakleszczeń? Dlaczego moje transakcje tylko-do-odczytu nie są tylko do odczytu? Kiedy oddać sterowanie transakcjami klientom zamiast obsługiwać je aspektowo? Jakie anomalie w spójności danych mi zagrażają?
Prezentacja na konferencji Java Developers Day 2012
Czym jest architektura i jak ją dokumentować?
Podczas mojej prezentacji pokażę, że do architektury da się podejść inżyniersko – z kalkulatorem i ekierką. Czas beztroskich artystów i wież z kości słoniowej bezpowrotnie przeminął…
Prezentacja Jakuba Kubryńskiego poświęcona architekturze Micro Services na przykładzie Spring Boot. Materiały z konferencji 4Developers 2014
Brutalna prawda o architekturze Microservices.
We’ll learn how to leverage eventual consistency and event-driven architecture with the use of pure Spring tools! For the fans of Functional Programming, you will learn how you can model your domain with just functions, pattern matching, left fold and immutability. Never lose information in your ORM-based system again!
I would like to share my experience with you by presenting the pros & cons of some useful tools and patterns, as well as pointing out to the different directions that you could explore on your own.
Common mistakes when moving to microservices that I'll discuss and provide solutions for: No realistic architecture process (architecture decisions too rigid, or not taken; infra vs domain; architecture guild vs no cooperation, knowledge sharing ) QA thinks testing end-to-end is possible Management wants to control deployment Devs not DevOps Not understanding event based architecture Not using the tools properly (Kafka) Relying on cloud provider shitty tools Error prone team setup Pivots vs domain vs team composition.
In this presentation you’ll see how to migrate a legacy application to work with stubs of external applications. We’ll show different ways of increasing your test reliability by writing adding contract tests of your API. You’ll see the difference between producer and consumer driven contracts.
W trakcie prezentacji dowiesz się jak przekładać informacji ze stormingu na decyzje architektoniczne dzięki strategicznym narzędziom DDD: destylacji kontekstów i mapowaniu kontekstów. Skupimy się na kilku konkretnych heurystykach, które podpowiadają jak dążyć do modularnego monolitu lub microservices, które mają realną autonomię dzięki: projektowani single source of truth i unikaniu single point of failure.
Architektury Oparte na Zdarzeniach stały się jednym z najpopularniejszych "buzz-wordów". Pokazywane są jako modelowa droga nowoczesnych, skalowalnych systemów. W trakcie prezentacji zagram adwokata diabła i pokażę, co może się nie udać. Pokażę, że to doświadczenie może być bolesne. Opowiem, jak można skończyć z rozproszonym monolitem i konkretnymi wskazówkami, jak temu zapobiec. Wyjaśnię wszystkie te enigmatyczne terminy, takie jak idempotentność, eventual consistency, at-least once delivery itp. Obalę kilka mitów i pokażę fakty bez ewangelizacji. Całość doprawiona będzie dawką zdrowego pragmatyzmu.