Jak system jest faktycznie zbudowany
Ta strona opisuje implementację stojącą za środowiskiem demonstracyjnym w tym serwisie, a nie schemat architektury systemu, który jeszcze nie istnieje. Tam, gdzie coś jest granicą, a nie integracją, opisujemy to jako granicę.
Czego dotyczy ta strona
ASTIN jest działającym systemem na poziomie demonstracyjnym, a nie wdrożoną platformą produkcyjną. To rozróżnienie ma znaczenie dla każdego, kto go ocenia, więc stawiamy je wprost.
- Encje dziedzinowe, zdarzenia i przejścia procesu w pełnym cyklu życia własności
- Trwałość po stronie serwera, przeżywająca restart, inicjowana z wersjonowanego zestawu danych
- Widoki API zależne od roli — każda rola otrzymuje inny ładunek danych, a nie odfiltrowany ekran
- Aktualizacja własności, przepięcie alokacji i wynikające z tego skutki w rejestrze rozliczeń
- Metadane dokumentów z uporządkowanymi wersjami i poziomami dostępu
- Historia aktywności udostępniana przez API wyłącznie przez dopisywanie
- Sterowana lokalizacją zmiana języka, waluty, sezonowości, terminologii rejestrowej i podmiotu wykonującego
- Uwierzytelnianie. Demo przełącza symulowane tożsamości; nie ma logowania, magazynu poświadczeń, zarządzania sesją ani odzyskiwania konta.
- Baza produkcyjna. Stan trzymany jest w dokumencie JSON z atomowym zapisem i szeregowaną kolejką zapisów — trwale i spójnie jak na demonstrację, ale to nie jest transakcyjna baza relacyjna.
- Przechowywanie treści dokumentów. Data room demonstruje metadane i wersjonowanie; nie przechowuje, nie szyfruje i nie udostępnia plików.
- Niezmienność kryptograficzna. Historia aktywności jest tylko do dopisywania, ponieważ API nie ma ścieżki aktualizacji ani usunięcia, a nie dlatego, że rekordy są łańcuchowane skrótem lub notarialnie utrwalane.
- Działające integracje. Granice rejestru, operatora najmu, płatności i weryfikacji tożsamości są odwzorowane i symulowane, a nie połączone.
- Zapewnienie bezpieczeństwa. Nie przeprowadzono testów penetracyjnych, certyfikacji ani formalnej oceny ochrony danych.
Model danych
Dziedzina modelowana jest przez encje i zdarzenia, a nie przez ekrany. Stan wynika z historii zdarzeń — i to sprawia, że ślad audytowy jest realny, a nie dekoracyjny.
Aktywo
Nieruchomość: identyfikacja, jurysdykcja, waluta, budżet operacyjny, profil sezonowości, status onboardingu.
Podmiot
Dowolny uczestnik — współwłaściciel, operator, broker, obserwator — z rolą i ustawieniem językowym.
Udział
Posiadanie w aktywie wyrażone w udziałach, z okresem obowiązywania.
Zdarzenie własnościowe
Zapis tylko do dopisywania każdej zmiany stanu własności, z podmiotem, datą i przyczyną.
Okres kalendarzowy
Datowany przedział z klasą sezonową, wagą i stanem dostępności.
Alokacja
Okres przypisany do udziału, w jednostkach ważonych i nocach fizycznych.
Decyzja
Status STAY / EARN / HOLD alokacji, z podmiotem i czasem ustawienia.
Pozycja rejestru
Zdarzenie przychodowe lub kosztowe powiązane z alokacją, właścicielem i kategorią.
Dokument i wersja
Skategoryzowany dokument z numerowanymi wersjami: data wydania, autor, status, poziom dostępu.
Sprawa zbycia
Proces wyjścia z etapami, ceną oczekiwaną, zainteresowaniami i granicą wykonania.
Zdarzenie audytowe
Podmiot, rola, akcja, obiekt i znacznik czasu dla każdej zmiany stanu w systemie.
Role i uprawnienia
Zaimplementowano cztery role, a ładunek danych zmienia się między nimi istotnie — nie przez ukrywanie przycisków, lecz przez zwracanie innych danych z API.
Pełna kontrola operacyjna: onboarding, kalendarz, alokacje, rozliczenia, sprawy zbycia, dokumenty.
Własny udział, alokacja i zestawienie. Widzi rekord aktywa i dokumenty na przysługującym poziomie dostępu.
Zwolniony inwentarz, dane rozliczeniowe do dostarczenia i prowadzone sprawy zbycia. Bez dostępu do pozycji innych właścicieli.
Tylko do odczytu, ograniczony czasowo, wyłącznie dokumenty i stany jawnie opublikowane na tym poziomie.
Zakres roli egzekwowany jest w warstwie API przy każdym żądaniu, więc rola nie sięgnie po dane innej roli manipulując klientem. To logika autoryzacji, a nie uwierzytelnianie: demo nie ma logowania, a przełącznik ról jawnie zmienia symulowane tożsamości. We wdrożeniu produkcyjnym za tym samym zakresem stanęłyby rzeczywiste, uwierzytelnione tożsamości.
Historia aktywności i wersjonowanie dokumentów
Zdarzenia aktywności są zapisywane wyłącznie przez dopisywanie w tym sensie, że API nie udostępnia ścieżki aktualizacji ani usunięcia. Klient prezentuje je w kolejności z podmiotem, rolą, akcją i obiektem, a każda zmiana stanu pojawia się natychmiast. Nie są łańcuchowane skrótem, podpisywane ani utrwalane zewnętrznie — jest to więc odporność na manipulację wynikająca z konstrukcji interfejsu, a nie niezmienność kryptograficzna.
Dokumenty mają uporządkowane wersje. Wersja zapisuje numer, datę wydania, autora, status i poziom dostępu; zastąpienie dokumentu dodaje wersję, zamiast nadpisywać treść, a wersja bieżąca jest wyliczana, a nie przechowywana jako flaga. Demonstracja odwzorowuje wyłącznie metadane — żadne pliki nie są wgrywane, przechowywane ani udostępniane.
Trwałość danych i wdrożenie
Demonstracja zapisuje dane po stronie serwera w dokumencie JSON zapisywanym atomowo przez szeregowaną kolejkę zapisów, inicjowanym z wersjonowanego zestawu danych. Stan przetrwa przeładowanie, zmianę przeglądarki i restart serwera, a równoległe żądania nie przeplotą się w cyklu odczyt-modyfikacja-zapis. Nie jest to pamięć przeglądarki ani stan zaszyty w komponentach — ale nie jest to też baza relacyjna i skalę dobrano do demonstracji, nie do obciążenia produkcyjnego.
Dostęp do magazynu odbywa się wyłącznie przez warstwę repozytoriów, więc przejście na PostgreSQL lub SQLite na potrzeby wdrożenia produkcyjnego jest zmianą w jednym module, a nie w całej aplikacji. Ta migracja to zadanie wdrożeniowe, a nie praca wykonana.
Aplikacja działa jako pojedynczy proces Node bez zewnętrznych zależności usługowych i bez kroku budowania wymaganego do jej uruchomienia. Strony marketingowe generowane są dodatkowo jako statyczny HTML, więc mogą być serwowane z dowolnego hostingu statycznego niezależnie od środowiska demonstracyjnego.
Zasady prywatności i bezpieczeństwa
To, co jest prawdą o tej implementacji dzisiaj, bez zawyżania.
Brak śledzenia zewnętrznego
Brak analityki, znaczników reklamowych i ciasteczek ustawianych przez ten serwis. Fonty i zasoby serwowane są z tej domeny, więc odwiedziny nie ujawniają niczego podmiotom trzecim.
Brak danych osobowych w demo
Scenariusz nie zawiera rzeczywistych osób. Podmioty są syntetyczne i tak oznaczone, a odwiedzających prosimy o niewprowadzanie prawdziwych danych osobowych.
Autoryzacja po stronie serwera
Zakres roli stosowany jest w warstwie API, a nie w interfejsie — choć, jak wskazano wyżej, bez uwierzytelniania za nim.
Domyślnie najmniejsze ujawnienie
Poziomy dostępu do dokumentów startują zamknięte; poszerzenie któregokolwiek jest jawną czynnością zapisywaną w historii aktywności.
Polityka Content Security Policy
Serwer wysyła restrykcyjną politykę CSP, zakaz osadzania w ramce, ochronę przed zgadywaniem typu MIME i politykę referrera przy każdej odpowiedzi.
Bezpieczeństwo transportu
TLS jest wymogiem hostingu produkcyjnego opisanym w instrukcji wdrożenia; nie zapewnia go sama aplikacja.
Nie przeprowadzono i nie deklarujemy żadnej certyfikacji bezpieczeństwa, testów penetracyjnych ani formalnej oceny ochrony danych. To czynności wdrożeniowe. Środowisko demonstracyjne należy traktować jak publiczną piaskownicę: nie zawiera niczego poufnego i każdy odwiedzający może je zresetować.
Granice integracji
Poniżej granice, wokół których zaprojektowano system. Żadna nie jest działającą integracją: demonstracja symuluje każdą wymianę, zamiast ją realizować, a podłączenie którejkolwiek to praca wdrożeniowa do ustalenia z kontrahentem.
Notariusz, rejestr gruntów lub DLD Registration Trustee. Sprawa zbycia zatrzymuje się na etapie wykonania do czasu zapisania potwierdzenia od uprawnionego podmiotu.
Zwolniony inwentarz w jedną stronę, dane rozliczeniowe w drugą. Modelowane jako ustrukturyzowana wymiana, gotowe pod integrację ze sprawozdawczością operatora.
W całości zewnętrzne. System zapisuje, że etap został zakończony; nigdy nie dotyka środków.
KYC/AML realizuje podmiot regulowany w transakcji; system zapisuje wynik, a nie dane źródłowe.
Lokalizacja
Ustawienie regionalne steruje językiem interfejsu, formatem liczb i dat, prezentacją waluty, profilem sezonowości, terminologią rejestrową oraz tożsamością podmiotu zewnętrznego wykonującego zbycie. Przełączenie scenariusza demonstracyjnego z Gran Canarii na Dubaj zmienia to wszystko spójnie — i właśnie tym mechanizmem produkt wchodzi na nowy rynek.
Zobacz to w działaniu
Środowisko demonstracyjne prowadzi syntetyczne aktywo przez pełny cykl życia, w czterech rolach operacyjnych, z trwałością danych — po przeładowaniu stan pozostaje.