Entuzjastów inżynierii oprogramowania (niekoniecznie związanych z Javą), zapraszam na 3 prezentacje, które odbędą się w ramach lokalnych JUGów (wstęp wolny również dla uczestników spoza JUG)
Wrocław 4 grudnia:
Tematy: Techniki strukturyzacji architektury oraz rozwinięcie do Architektury Ports & Adapters.
Szczegóły pojawią się na stronie grupy.
Szczecin 10 grudnia:
Tematy: Techniki strukturyzacji architektury oraz rozwinięcie do Architektury Ports & Adapters.
Szczegóły pojawią się na stronie grupy.
Kraków 13 grudnia:
Temat i miejsce ustalamy na grupie dyskusyjnej Polish JUG. Więcej info pojawi się gdy ustalimy szczegóły.
5 komentarzy:
W centralnym rysunku do Ports&Adapters widzę inspirację budowniczymi kościołów:)
Chyba trochę nadużywasz wzorca "Micro Kernel". MK to rozwiązanie, na "klonowanie" softu np.: firma robi soft na telefony dla różnych producentów, soft jest w zasadzie ten sam, ale każdy producent ma specyficzne wymagania. Sutkiem tego może być albo wielka pulpa, w której na twardo wyłącza się features konkretnym telefonom (@see w tańszej wersji jednego samochodów "usunięto" komputer pokładowy, poprzez zaklejenie go taśmą na desce rozdzielczej) albo kilka kilkanaście klonów tego samego oprogramowania, które różnią się od siebie w kilku aspektach.
No i w końcu mamy MK, którego zaprojektowanie jest dość dużym wyzwaniem, wbrew temu co można by wnioskować po prostokącikach, które przestawiają strukturę wzorca. MK wydziela wspólną część, a pozwala zmniejszenie czasochłonności implementowania różnicy. To interpretacja dla aplikacji typu "business". Któryś tam Windows też był oparty MK.
To, co dalszej części prezentacji wygląda jak fragment plastra miodu (oglądałem tylko na prezi, niestety nie na żywo:( ), a co jest opisane jako "Kernel" przypomina bardziej evansowe domain, core domain albo bounded contex, ale nie MK.
pozdr,
mb
Tak, treścią centrum "plastra" jest Bounded Context z DDD.
Ale formę nazwano tutaj Kernel w Hexagodnie.
Odniesienie do MK może być nieco na siłę - ale to kwestia interpretacji. Jakoś trzeba to nazwać, więc ludzie szukając nazwy czerpią z już znanych metafor.
Metafor MK jest szczególnie użyteczna w kontekście testów end-to-end komponentowych, gdzie "wyjmujemy" jądro i zaślepiamy porty "dolne" (adaptery typu mock/stub/fake) i pobudzamy porty "górne". Nieco jak jądra żyjące w środowiku różnych telewizorów.
Spox, ale to jest właśnie potęga nadawania nazw. Jeśli użyjesz nazwy MK, to zawsze zdarzą się tacy jak ja, którzy będą zgłaszać obiekcje, bo czegoś tam nie zrozumieli.
Nowe słowa to właśnie esencja sukcesu Evansa i Schwabera. Niby wzięli to, co już istnieje (OOP i lean manufacturing) i nadając nowe nazwy oderwali się od dotychczasowego rozmienia pewnych spraw i zamiast ścierać się z istniejącym stanem rzeczy, stworzyli sobie własną przestrzeń memów, w której to oni rozdają karty. Kto nazywa, ten rządzi :)
Można gdzieś zobaczyć nagrania video z tych prezentacji ?
wydaje mi się, że nikt ich nie rejestrował
Prześlij komentarz