SOWA OPAC : Katalog komputerowy książek, czasopism i zbiorów specjalnych

3 wyniki

Książka

W koszyku

Autor

Evans Eric (1962- ) Szpoton Rafał

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

DDD Programowanie (informatyka) Systemy informatyczne

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

Na okładce podtytuł: zmień sposób myślenia o projektowaniu systemów informatycznych. W książce także ISBN oryginału.

Bibliografia, netografia na stronach 565-566. Indeks.

Zastosowanie modelu dziedziny Przydatność modelu w projektowaniu sterowanym dziedziną Istota programu Rozdział 1. Przetwarzanie wiedzy Elementy wydajnego modelowania Przetwarzanie wiedzy Ciągła nauka Projekt bogaty w wiedzę Modele dogłębne Rozdział 2. Komunikacja i użycie języka Język wszechobecny Modelowanie na głos Jeden zespół, jeden język Dokumenty i diagramy Spisane dokumenty projektowe Wykonywalna podstawa Modele objaśniające Rozdział 3. Związanie modelu z implementacją Projektowanie sterowane modelem Paradygmaty modelowania i narzędzia wspierające Projekt mechaniczny Projekt sterowany modelem Odkrywanie szkieletu dlaczego modele są ważne dla użytkowników Modelowanie praktyczne II Elementy składowe projektu sterowanego modelem Rozdział 4. Wyizolowanie dziedziny Architektura warstwowa Powiązanie warstw Szkielety architektury To w warstwie dziedziny żyje model Antywzorzec inteligentnego interfejsu użytkownika Inne rodzaje izolacji Rozdział 5. Wyrażenie modelu w programie Asocjacje ENCJE (zwane również obiektami referencyjnymi) Modelowanie ENCJI Projektowanie operacji na tożsamości WARTOŚCI Projektowanie OBIEKTÓW WARTOŚCI Projektowanie asocjacji korzystających z WARTOŚCI USŁUGI USŁUGI a wyizolowana warstwa dziedziny Ziarnistość Dostęp do USŁUG MODUŁY (zwane również PAKIETAMI) MODUŁY zwinne (agile modules) Pułapki tworzenia pakietów na podstawie wymogów infrastruktury Paradygmaty modelowania Dlaczego dominuje paradygmat obiektowy? Nieobiekty w świecie obiektowym Utrzymywanie PROJEKTU STEROWANEGO MODELEM w przypadku łączenia paradygmatów Rozdział 6. Cykl życia obiektu dziedziny AGREGATY FABRYKI Wybór FABRYK oraz ich miejsc Kiedy potrzebujesz jedynie konstruktora Projektowanie interfejsu Gdzie mieści się logika niezmienników? FABRYKI ENCJI a FABRYKI WARTOŚCI Odtwarzanie zachowanych obiektów REPOZYTORIA Odpytywanie REPOZYTORIUM Kod klienta, w przeciwieństwie do programistów, ignoruje implementację REPOZYTORIUM Implementacja REPOZYTORIUM Praca ze szkieletami architektury Relacje z FABRYKAMI Projektowanie obiektów dla relacyjnych baz danych Rozdział 7. Użycie języka przykład rozszerzony Prezentacja systemu logistycznego dla ładunku Izolowanie dziedziny wprowadzenie aplikacji Rozróżnianie ENCJI oraz WARTOŚCI Role (rola) oraz inne atrybuty Projektowanie asocjacji w dziedzinie logistyki morskiej Granice AGREGATU Wybór REPOZYTORIÓW Przeglądanie scenariuszy Przykładowa funkcjonalność aplikacji zmiana miejsca przeznaczenia ładunku Przykładowa funkcjonalność aplikacji powtórzenie operacji Tworzenie obiektów FABRYKI oraz konstruktory klasy Cargo Dodanie operacji obsługi Przerwa na refaktoring projekt alternatywny AGREGATU Cargo MODUŁY w modelu logistyki morskiej Nowa funkcjonalność sprawdzanie przydziału Łączenie dwóch systemów Wzbogacanie modelu segmentacja biznesu Poprawa wydajności Ostateczna wersja III Refaktoryzacja ku głębszemu zrozumieniu Poziomy refaktoryzacji Modele dogłębne Model dogłębny/projekt elastyczny Proces odkrywania Rozdział 8. Moment przełomowy Historia pewnego przełomu Przyzwoity model, lecz wciąż... Moment przełomowy Model pogłębiony Otrzeźwiająca decyzja Zapłata Możliwości Koncentracja na podstawach Epilog potok nowych spostrzeżeń Rozdział 9. Odkrywanie pojęć niejawnych Wyciąganie pojęć Nasłuchiwanie języka Analiza dziwnej implementacji Rozmyślanie nad sprzecznościami Czytanie książki Wielokrotne powtarzanie prób W jaki sposób zamodelować mniej oczywiste pojęcia Bezpośrednie ograniczenia Procesy jako obiekty dziedziny SPECYFIKACJA Zastosowanie SPECYFIKACJI w implementacji Walidacja Wybór (lub odszukiwanie) Tworzenie na zamówienie (generowanie) Rozdział 10. Projekt elastyczny INTERFEJSY UJAWNIAJĄCE ZAMIAR FUNKCJE BEZ EFEKTÓW UBOCZNYCH ASERCJE Teraz widzimy lepiej ZARYSY KONCEPCYJNE Nieprzewidziana zmiana KLASY SAMODZIELNE ZAMKNIĘCIE OPERACJI Projektowanie deklaratywne Języki właściwe dziedzinie Deklaratywny styl projektowania Rozszerzenie SPECYFIKACJI w stylu deklaratywnym Łączenie SPECYFIKACJI przy użyciu operatorów logicznych Subsumpcja Kierunki ataku Definiowanie poddziedzin W miarę możliwości polegaj na ustalonym formalizmie Wstępny projekt dystrybucji płatności Oddzielanie poleceń oraz FUNKCJI BEZ EFEKTÓW UBOCZNYCH Ujawnianie ukrytych pojęć Obiekt SharePie staje się WARTOŚCIA kaskada spostrzeżeń Elastyczność nowego projektu Rozdział 11. Stosowanie wzorców analitycznych Wzorce analityczne stanowią wiedzę do wykorzystania Rozdział 12. Powiązanie wzorców projektowych z modelem STRATEGIA (zwana również POLITYKĄ) KOMPOZYT Dlaczego nie wzorzec PYŁKU (FLYWEIGHT)? Rozdział 13. Refaktoryzacja ku głębszemu zrozumieniu Początek Zespoły poszukiwawcze Wcześniejsze odkrycia Projekt dla programistów Wyczucie czasu Kryzys jako źródło możliwości IV Projekt strategiczny Rozdział 14. Utrzymywanie integralności modelu KONTEKST ZWIĄZANY Rozpoznawanie odprysków pojęciowych w KONTEKŚCIE ZWIĄZANYM CIĄGŁA INTEGRACJA MAPA KONTEKSTÓW Testowanie na granicach KONTEKSTU Organizacja oraz dokumentacja MAP KONTEKSTÓW Relacje pomiędzy KONTEKSTAMI ZWIĄZANYMI JĄDRO WSPÓŁDZIELONE ZESPOŁY PROGRAMISTYCZNE KLIENTA DOSTAWCY KONFORMISTA WARSTWA ZAPOBIEGAJĄCA USZKODZENIU Projektowanie interfejsu WARSTWY ZAPOBIEGAJĄCEJ USZKODZENIU Implementacja WARSTWY ZAPOBIEGAJĄCEJ USZKODZENIU Opowieść ku przestrodze ODDZIELNE DROGI USŁUGA OTWARTEGO GOSPODARZA JĘZYK OPUBLIKOWANY Unifikacja słonia Wybór strategii kontekstu modelu Decyzja zespołowa lub wyższa Stawianie siebie w kontekście Przekształcanie granic Akceptacja tego, czego nie możemy zmienić wyznaczanie zewnętrznych systemów Relacje z systemami zewnętrznymi System w projektowaniu Dostosowanie do specjalnych potrzeb przy użyciu odrębnych modeli Wdrożenie Kompromis Kiedy projekt już trwa Transformacje Łączenie KONTEKSTÓW ODDZIELNE DROGI JĄDRO WSPÓŁDZIELONE Łączenie KONTEKSTÓW JĄDRO WSPÓŁDZIELONE CIĄGŁA INTEGRACJA Wygaszanie starego systemu USŁUGA OTWARTEGO GOSPODARZA JĘZYK OPUBLIKOWANY Rozdział 15. Destylacja DZIEDZINA GŁÓWNA Wybór RDZENIA dziedziny Kto wykonuje prace? Zwiększanie destylacji PODDZIEDZINY OGÓLNE Rozwiązanie 1. Gotowy, standaryzowany produkt Rozwiązanie 2. Opublikowany projekt lub model Rozwiązanie 3. Oddelegowanie implementacji Rozwiązanie 4. Samodzielna implementacja Ogólny nie oznacza możliwy do ponownego wykorzystania Zarządzanie ryzykiem projektowym OPIS WIZJI DZIEDZINY RDZEŃ WYRÓŻNIONY Dokument destylacji RDZEŃ oznaczony Dokument destylacji jako narzędzie procesowe SPÓJNE MECHANIZMY OGÓLNE PODDZIEDZINY a SPÓJNE MECHANIZMY Kiedy MECHANIZM jest częścią DZIEDZINY GŁÓWNEJ Destylacja do stylu deklaratywnego RDZEŃ ODDZIELONY Koszt utworzenia RDZENIA ODDZIELONEGO Rozwijanie decyzji zespołowych RDZEŃ ABSTRAKCYJNY Głęboka destylacja modelu Wybór celów refaktoryzacji Rozdział 16. Struktury dużej skali PORZĄDEK EWOLUCYJNY METAFORA SYSTEMU Dlaczego nie potrzebujemy metafory naiwnej WARSTWY ODPOWIEDZIALNOŚCI Odpowiedzialności operacyjne Odpowiedzialności potencjału Odpowiedzialności wsparcia decyzji W jaki sposób struktura wpływa na bieżący projekt? Wybór odpowiednich warstw POZIOM WIEDZY SZKIELET KOMPONENTÓW DOŁĄCZANYCH Tworzenie elementu Wybierz materiały Tworzenie elementu Jak ograniczająca powinna być struktura? Refaktoryzacja ku lepiej dopasowanej strukturze Minimalizm Komunikacja oraz samodyscyplina Restrukturyzacja przyczynia się do projektu elastycznego Destylacja zmniejsza obciążenie Rozdział 17. Łączenie strategii Łączenie struktur dużej skali z KONTEKSTAMI ZWIĄZANYMI Łączenie struktur dużej skali oraz destylacji Najpierw oszacowanie Kto określa strategię? Powstawanie struktury w trakcie tworzenia aplikacji Zespół architektoniczny skoncentrowany na kliencie Sześć podstawowych kryteriów dotyczących podejmowania strategicznych decyzji projektowych Decyzja musi dotrzeć do całego zespołu. Proces podejmowania decyzji musi uwzględniać uwagi. Plan musi umożliwiać rozwój. Zespoły architektów nie mogą wyciągać wszystkich najlepszych i najbardziej błyskotliwych programistów. Projekt strategiczny wymaga minimalizmu oraz pokory. Obiekty są specjalizowane, programiści są uniwersalni. To samo dotyczy szkieletów technicznych Nie twórz szkieletów dla osób nierozgarniętych. Wystrzegaj się planu głównego

dostępna do wypożyczenia

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Wypożyczalnia

Są egzemplarze dostępne do wypożyczenia: sygn. 152756 N (1 egz.)

Książka

W koszyku

Koncepcja Domain-driven design : dostosowywanie architektury aplikacji do strategii biznesowej / Vlad Khononov ; przekład: Radosław Meryk. - Gliwice : Helion, © 2022. - 290, [6] stron : fotografie, ilustracje, wykresy ; 24 cm.

Autor

Khononov Vlad Meryk Radosław

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

DDD Programowanie (informatyka)

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

W książce także ISBN oryginału.

Bibliografia, netografia na stronach 289-290.

Część I. Projektowanie strategiczne 1.Analiza Dziedzin Biznesowych Co to jest Dziedzina Biznesowa? Co to jest Poddziedzina? Typy Poddziedzin Porównywanie Poddziedzin Identyfikowanie granic Poddziedzin Przykłady analizy Dziedziny Gigmaster BusVNext Kim są eksperci dziedzinowi? 2.Odkrywanie wiedzy dziedzinowej Problemy biznesowe Odkrywanie wiedzy Komunikacja Co to jest Język Wszechobecny? Język biznesu Scenariusze Spójność Model Dziedziny Biznesowej Co to jest „model"? Skuteczne modelowanie Modelowanie Dziedziny Biznesowej Ciągły wysiłek Narzędzia Wyzwania 3.Zarządzanie złożonością Dziedziny Niespójne modele Co to jest Kontekst Ograniczony? Granice modelu Język Wszechobecny dokładniej Zakres Kontekstu Ograniczonego Konteksty Ograniczone a Poddziedziny Poddziedziny Konteksty Ograniczone Wzajemne oddziaływanie między Poddziedzinami a Kontekstami Ograniczonymi Granice Granice fizyczne Granice własności Konteksty Ograniczone w prawdziwym życiu Dziedziny semantyczne Nauka Kupowanie lodówki 4.Integracja Kontekstów Ograniczonych Kooperacja Partnerstwo Wspólne Jądro Klient-Dostawca Konformista Warstwa Antykorupcyjna Usługa Otwartego Hosta Różne Drogi Problemy z komunikacją Poddziedziny Ogólne Różnice w modelach Mapa Kontekstu Utrzymanie Ograniczenia Część II. Projektowanie taktyczne 5.Implementacja prostej Logiki Biznesowej Skrypt Transakcji Implementacja To nie jest takie proste! Kiedy używać Skryptu Transakcji Aktywny Rekord Implementacja Kiedy używać wzorca Aktywny Rekord Bądź pragmatyczny 6.Rozwiązywanie problemów ze złożoną Logiką Biznesową Historia Model Dziedziny Implementacja Bloki konstrukcyjne Zarządzanie złożonością 7.Modelowanie wymiaru czasu Event Sourcing Wyszukiwanie Analiza Źródło prawdy Magazyn zdarzeń Model Dziedziny ze źródłem w postaci zdarzeń Zalety Wady Często zadawane pytania Wydajność Usuwanie danych Dlaczego nie mogę po prostu...? 8.Wzorce architektoniczne Logika Biznesowa a wzorce architektoniczne Architektura Warstwowa Warstwa Prezentacji Warstwa Logiki Biznesowej Warstwa Dostępu Do Danych Komunikacja między warstwami Odmiany Kiedy używać Architektury Warstwowej? Porty i Adaptery Terminologia Zasada inwersji zależności Integracja komponentów infrastrukturalnych Odmiany Kiedy używać wzorca Porty i Adaptery? Segregacja Odpowiedzialności za Polecenia i Zapytania Modelowanie poliglotyczne Implementacja Projekcje Modeli Odczytu Wyzwania Segregacja modeli Kiedy używać CQRS? 9.Wzorce komunikacji Tłumaczenie modelu Bezstanowe tłumaczenie modelu Stanowe tłumaczenie modelu IntegracjaAgregatów Skrzynka Nadawcza Saga Menedżer Procesu Część III. Zastosowanie DDD w praktyce 10.Heurystyki projektowe Heurystyka Konteksty Ograniczone Wzorce implementacji Logiki Biznesowej Wzorce architektoniczne Strategia testowania Piramida Testowania Romb Testowania Odwrócona Piramida Testowania Drzewo decyzyjne projektu taktycznego 11.Zmieniające się decyzje projektowe Zmiany w Dziedzinach Podstawowa na Ogólną Ogólna na Podstawową Pomocnicza na Ogólną Pomocnicza na Podstawową Podstawowa na Pomocniczą Ogólna na Pomocniczą Problemy projektu strategicznego Problemy projektu taktycznego Skrypt Transakcji na Aktywny Rekord Aktywny Rekord na Model Dziedziny Model Dziedziny na Model Dziedziny ze źródłem w postaci zdarzeń Generowanie przeszłych przejść Modelowanie zdarzeń migracji Zmiany organizacyjne Partnerstwo na Klient-Dostawca Klient-Dostawca na Różne Drogi Wiedza dziedzinowa Rozwój Poddziedziny Konteksty Ograniczone Agregaty 12.EventStorming Co to jest EventStorming? Kto powinien wziąć udział w warsztatach EventStorming? Czego potrzebujesz do zorganizowania sesji EventStorming? Przebieg warsztatów EventStorming Krok 1. Nieustrukturyzowana eksploracja Krok 2. Osie czasu Krok 3. Możliwe problemy Krok 4. Kluczowe zdarzenia Krok 5. Polecenia Krok 6. Reguły Krok 7. Modele Odczytu Krok 8. Systemy zewnętrzne Krok 9. Agregaty Krok 10. Konteksty Ograniczone Odmiany Kiedy korzystać z warsztatów EventStorming? Wskazówki dotyczące facylitacji Obserwuj dynamikę Zdalne sesje EventStorming 13.Projekt oparty na Dziedzinie w praktyce Analiza strategiczna Opis Dziedziny Biznesowej Poznaj aktualny projekt Strategia modernizacji Modernizacja strategiczna Modernizacja taktyczna Pielęgnuj Język Wszechobecny Praktyczny projekt DDD Promowanie projektu DDD Ujawnij metodologię DDD Część IV. Związki z innymi metodologiami i wzorcami 14.Mikrousługi Co to jest usługa? Co to jest „mikrousługa"? Metoda jako usługa: czy to doskonałe mikrousługi? Cel projektu Złożoność systemu Mikrousługi jako usługi głębokie Mikrousługi jako moduły głębokie Projektowanie DDD a granice mikrousług Konteksty Ograniczone Agregaty Poddziedziny Kompresowanie publicznych interfejsów mikrousług Usługa Otwartego Hosta Warstwa Antykorupcyjna 15.Architektura sterowana zdarzeniami Architektura sterowana zdarzeniami Zdarzenia Zdarzenia, Polecenia i Komunikaty Struktura Rodzaje zdarzeń Projektowanie integracji sterowanej zdarzeniami Rozproszona Wielka Kula Błota Sprzężenie czasowe Sprzężenie funkcjonalne Sprzężenie implementacji Refaktoryzacja kodu integracji sterowanej zdarzeniami Heurystyka projektu sterowanego zdarzeniami 16.Siatka danych Analityczny model danych a transakcyjny model danych Tabela faktów Tabela wymiarów Modele analityczne

dostępna do wypożyczenia

1 placówka posiada w zbiorach tę pozycję. Rozwiń informację, by zobaczyć szczegóły.

Wypożyczalnia

Są egzemplarze dostępne do wypożyczenia: sygn. 153029 N (1 egz.)

Książka

W koszyku

Domain-Driven Design dla .NET Core : jak rozwiązywać złożone problemy podczas projektowania architektury aplikacji / Alexey Zimarev ; przekład: Lech Lachowski. - Gliwice : Helion, copyright 2021. - 424 strony : fotografie, ilustracje, wykresy ; 24 cm.

Autor

Zimarev Alexey Lachowski Lech

Forma i typ

Książki Publikacje fachowe

Odbiorca

Programiści

Temat

DDD .NET Programowanie (informatyka)

Gatunek

Podręcznik

Dziedzina i ujęcie

Informatyka i technologie informacyjne

W książce także ISBN oryginału.

Bibliografie, netografie przy niektórych rozdziałach.

Rozdział 1. Dlaczego projektowanie dziedzinowe? 19 Zrozumieć problem 20 Przestrzeń problemu i przestrzeń rozwiązania 20 Co poszło nie tak z wymaganiami? 22 Jak radzić sobie ze złożonością? 23 Rodzaje złożoności 23 Klasyfikowanie złożoności 26 Podejmowanie decyzji i błędy poznawcze 29 Wiedza 32 Wiedza dziedzinowa 32 Unikanie ignorancji 34 Rozdział 2. Język i kontekst 37 Język wszechobecny 37 Język dziedzinowy 38 Wyraźne określanie rzeczy dorozumianych 41 Język i kontekst 47 Rozdział 3. EventStorming 53 EventStorming 54 Język modelowania 55 Wizualizacja 57 Porady dotyczące organizowania warsztatów EventStorming 58 Kogo zaprosić? 58 Przygotowanie przestrzeni 59 Warsztaty 61 Nasz pierwszy model 68 Rozdział 4. Projektowanie modelu 75 Model dziedziny 75 Co reprezentuje model? 76 Anemiczny model dziedziny 77 Co należy uwzględnić w modelu dziedziny? 78 EventStorming na poziomie projektu 82 Poszerzanie wiedzy 82 Przygotowanie do warsztatów 83 Notacja rozszerzona 83 Modelowanie dziedziny referencyjnej 88 Rozdział 5. Implementacja modelu 93 Wymagania techniczne 93 Rozpoczęcie implementacji 94 Tworzenie projektów 94 Framework 95 Przełożenie modelu na kod 96 Encje 97 Dodawanie zachowania 100 Zapewnianie poprawności 101 Ograniczenia dla wartości wejściowych 102 Obiekty wartości 103 Zdarzenia dziedzinowe w kodzie 127 Zdarzenia dziedzinowe jako obiekty 128 Generowanie zdarzeń 131 Zdarzenia zmieniają stan 134 Rozdział 6. Działanie za pomocą poleceń 141 Wymagania techniczne 141 Otoczenie modelu dziedziny 142 Udostępnianie internetowego interfejsu API 142 Warstwa aplikacji 149 Obsługa poleceń 152 Wzorzec procedury obsługi poleceń 152 Usługa aplikacji 156 Rozdział 7. Granica spójności 167 Wymagania techniczne 167 Spójność modelu dziedziny 168 Granice transakcji 168 Wzorzec Agregat 173 Ochrona niezmienników 181 Analiza ograniczeń dla polecenia 182 Egzekwowanie reguł 189 Encje wewnątrz agregatu 192 Rozdział 8. Utrwalanie agregatów 203 Wymagania techniczne 203 Utrwalanie agregatów 204 Repozytorium i jednostki pracy 204 Implementacja dla RavenDB 206 Implementacja Entity Framework Core 221 Rozdział 9. CQRS - strona odczytu 233 Wymagania techniczne 234 Dodawanie profilów użytkowników 234 Zagadnienia dotyczące dziedziny profilu użytkownika 235 Strona aplikacji dla profilu użytkownika 242 Strona zapytań 250 CQRS i konflikt między odczytami a zapisami 250 Zapytania i modele odczytu 252 Implementowanie zapytań 254 API zapytań 254 Implementacja zapytań dla RavenDB 257 Implementacja zapytań dla frameworku encji 264 Rozdział 10. Event Sourcing 271 Wymagania techniczne 272 Dlaczego Event Sourcing 273 Problemy z utrwalaniem stanu 273 Czym jest Event Sourcing? 277 Event Sourcing wokół nas 278 Agregaty pozyskiwane ze zdarzeń 279 Strumienie zdarzeń 279 Magazyny zdarzeń 281 Utrwalanie oparte na zdarzeniach 283 Rozdział 11. Rzutowania i kwerendy 303 Zdarzenia i zapytania 304 Budowanie modeli odczytu na podstawie zdarzeń 305 Rzutowania 306 Subskrypcje 308 Implementacja rzutowań 311 Subskrypcje nadganiające 311 Rzutowania międzyagregatowe 320 Rzutowanie zdarzeń z dwóch agregatów 321 Wzbogacanie modeli odczytu 331 Kwerendowanie w rzutowaniach 332 Konwertowanie zdarzeń 335 Magazyn trwały 340 Punkty kontrolne 340 Utrwalanie modeli odczytu 344 Rozdział 12. Kontekst ograniczony 355 Pułapka pojedynczego modelu 356 Zaczynaj od rzeczy małych 356 Znowu złożoność 357 Wielka kula błota 359 Konstruowanie systemów 363 Granice językowe 364 Autonomia zespołu 369 Rozdział 13. Podział systemu 375 Kiedy, co i jak? 375 Kiedy dzielić? 376 Co dzielić? 378 Jak podzielić? 380 Różne spojrzenia na projektowanie systemów 382 Proces projektowania 383 Dzielenie encji 387 Budowa systemu modułowego 387 Moduły wewnątrz jednego rozwiązania 389 Struktura modułu 392 Budowanie systemu 403 Podłączanie modułów do aplikacji 404 Integracja 405 Interfejs użytkownika 412 Interfejs użytkownika ponad granicami 413 Mikrousługi 417 Kiedy nie stosować systemów rozproszonych 418 Jak stosować systemy rozproszone 419

Sygnatura czytelni BWEAiI: XII L 48

dostępna do wypożyczenia

Ta pozycja znajduje się w zbiorach 2 placówek. Rozwiń listę, by zobaczyć szczegóły.

Wypożyczalnia

Są egzemplarze dostępne do wypożyczenia: sygn. 151437 (1 egz.)

Biblioteka WEAiI

Egzemplarze są dostępne wyłącznie na miejscu w bibliotece: sygn. 151436 N (1 egz.)