Dlaczego Twój system nie wie kim jest Twój klient?
Organizacje mogą mieć dziesiątki systemów, setki tabel w bazach danych i tysiące pól opisujących klientów, pracowników, dostawców, partnerów. I prawie zawsze ten sam problem: każdy system inaczej rozumie kim jest podmiot, z którym firma robi interesy.
W CRM klient to rekord z emailem i telefonem. W ERP to numer kontrahenta z NIP-em i warunkami płatności. W HR to pracownik z PESEL-em i datą zatrudnienia. W systemie prawnym to strona umowy z adresem korespondencyjnym. Cztery systemy, cztery różne odpowiedzi na to samo pytanie: kim jest ta osoba lub firma?
To nie jest problem techniczny do rozwiązania kolejną integracją. To jest problem analityczny wynikający z braku wspólnego modelu tego czym jest podmiot w organizacji.
Archetyp Party, jak jedno pytanie może uporządkować chaos
Archetypy biznesowe to sprawdzone wzorce modelowania, opisane przez Arlowa i Neustadta, rozwinięte przez Fowlera. Nie są teorią akademicką tylko narzędziem które od dwudziestu lat pomagają analitykom i architektom budować spójne modele domen biznesowych.
Jednym z ośmiu fundamentalnych archetypów w rozwiązaniu DOcForge jest Party opisujący podmiot. Odpowiada na pytanie: kto bierze udział w procesach biznesowych?
Zasada jest prosta. Party to byt który istnieje niezależnie od jakiegokolwiek procesu. Gdyby wszystkie zamówienia, umowy i sprawy się zakończyły to podmiot nadal figuruje w rejestrze. Jan Kowalski nie przestaje istnieć gdy zakończy się jego ostatnie zamówienie. Kancelaria prawna XYZ nie znika gdy zamknie ostatnią sprawę.
Party ma dokładnie dwa podtypy i jest to jedno z ważniejszych założeń, tylko dwa. Co ważne, nie ma możliwości aby podmiot był w dwóch podtypach jednocześnie. Jest albo osobą fizyczną, albo organizacją. To jest ograniczenie które ma konkretną przyczynę prawną.
Dlaczego podział Person/Organization jest wymuszony przez RODO
RODO (Rozporządzenie 2016/679) stosuje się do osób fizycznych. Dane osobowe to informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. NIP firmy nie jest daną osobową. PESEL osoby jest. Email firmowy info(at)firma.pl nie podlega RODO. Email jan.kowalski(at)firma.pl już tak ponieważ identyfikuje osobę.
Jeśli Twój model danych traktuje klienta jako jeden byt bez rozróżnienia czy to człowiek czy firma to pojawia się problem. Nie wiesz do których rekordów stosować prawo do usunięcia (art. 17), prawo dostępu (art. 15), prawo do przenoszenia (art. 20). Nie wiesz które pola szyfrować, które anonimizować, które retencjonować.
Archetyp Party rozwiązuje to na poziomie modelu. Reguła projektowa mówi: Party jest wyłącznie Person lub Organization, nigdy obydwoma. Analityk podejmuje tę decyzję raz, przy modelowaniu domeny. Inspektor ochrony danych wie które rekordy podlegają RODO: te z podtypem Person.
Przypadek specjalny: jednoosobowa działalność gospodarcza
Tu jest pułapka na którą wpada większość systemów. Jan Kowalski prowadzący jednoosobową działalność gospodarczą ma NIP i REGON tak jak firma. Ma wpis w CEIDG jak firma. Wystawia faktury VAT jak firma. Więc zazwyczaj modeluje się go jako organizację.
Tyle że podmiotem prawnym JDG jest człowiek, nie odrębna jednostka. Dane JDG w tym NIP i REGON to dane osobowe podlegające pełnej ochronie RODO. Archetyp Party ma na to osobną regułę: JDG to zawsze Person, nie Organization. Nazwa handlowa (Kancelaria Doradztwa Jan Kowalski) to atrybut osoby z typem użycia nazwa handlowa i datą wpisu CEIDG nie osobny podmiot.
Co to daje w praktyce
Gdy analityk modeluje domenę z archetypem Party, każdy podmiot przechodzi przez zestaw pytań diagnostycznych. Dwa z nich są krytyczne , odpowiedź nie natychmiast wyklucza byt z tego archetypu:
Pierwsze pytanie: czy ten byt istnieje niezależnie od jakiegokolwiek procesu?
Jeśli nie: to nie jest podmiot. To jest rola (np. klient to rola którą człowiek pełni w kontekście transakcji) albo zdarzenie (np. zamówienie to fakt biznesowy, nie podmiot).
Drugie pytanie: czy ten byt jest albo człowiekiem albo podmiotem prawnym i tylko jednym z tych dwóch? Jeśli analityk nie potrafi odpowiedzieć pipeline w DocForge się zatrzymuje. Nie ma domyślnej odpowiedzi. Trzeba ustalić z klientem.
Po klasyfikacji podmiot dostaje obowiązkowy identyfikator UUID, nigdy NIP, PESEL ani email jako klucz główny (bo identyfikatory zewnętrzne mogą się zmieniać np. firma zmienia NIP przy przekształceniu, osoba zmienia nazwisko). Identyfikatory zewnętrzne z datami ważności.
Dane handlowe takie jak np. warunki płatności, limit kredytowy, segment nie żyją w podmiocie. Żyją w roli. Zmiana warunków płatności klienta nie modyfikuje rekordu tożsamości osoby. Zmiana nazwy firmy po przekształceniu nie kasuje historii transakcji ponieważ transakcje to referencja danych z dnia zdarzenia, nie aktualny stan podmiotu.
Od modelu do systemu czyli dlaczego AI zmienia reguły gry
Analityk tworzy model z archetypami na poziomie analizy biznesowej. Programista bierze ten model i podejmuje decyzje techniczne. Do niedawna to był koniec historii, dwie osoby, dwa etapy, ręczna praca na obu końcach.
Dziś w tym procesie pojawia się trzeci uczestnik: AI i inny sposób komunikacji. Ustrukturyzowany model z archetypami daje efekt którego nie daje żaden dokument w prozie.
Gdy model domeny jest zapisany w jednoznacznym formacie: z typami, regułami, stanami, relacjami to AI potrafi go przeczytać i przetworzyć tak samo jak człowiek. Nie interpretuje, nie zgaduje, nie halucynuje. Ma konkretne dane: Klient to Party.Person, podlega RODO, klucz główny UUID, dane handlowe w roli, nie w podmiocie.
Z takiego modelu AI generuje prototypy aplikacji w postaci klasy domenowej, schematu bazy danych, walidatorów, API. Nie gotowy produkt, ale działający szkielet który programista może ocenić w godziny zamiast budować tygodniami. MVP powstaje szybciej bo AI nie wymyśla struktury od zera tylko odczytuje ją z modelu analityka.
Ale to nie jest jedyne zastosowanie.
Dokumentacja RODO generowana z modelu
Ten sam model, z którego programista buduje system, pozwala AI wygenerować dokumentację zgodności z RODO. Nie jest to osobny dokument pisany przez prawnika od zera tylko dokument wynikający z tego samego źródła prawdy co kod. DocForge robi to automatycznie.
Np. rejestr czynności przetwarzania (art. 30 RODO)? AI czyta model: każdy byt z podtypem Person ma oznaczenie rodo=true, każdy jego atrybut ma typ (imię, email, PESEL), każda relacja mówi kto ma dostęp i dlaczego. Rejestr generuje się automatycznie i jest spójny z systemem, bo pochodzi z tego samego modelu.
Odpowiedź na żądanie usunięcia danych (art. 17)? Model mówi: usuń Party.Person z UUID X, ale zachowaj zanonimizowane PartySummary na zdarzeniach (bo zdarzenia są niemutowalne a to reguła innego archetypu: MomentInterval). AI generuje procedurę usuwania która respektuje obie reguły jednocześnie: RODO i niezmienność zdarzeń biznesowych.
Spójność od analizy do audytu
Kluczowa decyzja, że Jan Kowalski z JDG to Person a nie Organization, że email nie jest kluczem głównym, że dane na fakturze to zamrożona migawka, ta decyzja jest podjęta raz, na poziomie analizy. Nie w kodzie, nie w bazie, nie w dokumentacji RODO osobno. W modelu.
Z tego jednego modelu wynikają trzy rzeczy jednocześnie: struktura systemu którą buduje programista, prototyp który generuje AI i dokumentacja RODO którą weryfikuje inspektor ochrony danych. Wszystkie trzy są spójne ponieważ pochodzą z tego samego źródła.
I gdy za dwa lata przyjdzie audyt RODO i zapyta: które rekordy w systemie zawierają dane osobowe, kto ma do nich dostęp i jak długo je przechowujecie? to odpowiedź nie wymaga przeszukiwania tabel, analizowania kodu ani wyciągania dokumentacji z szuflady. Model to wie od początku. AI generuje raport w minuty.
To jest wartość ustrukturyzowanej analizy: nie tylko jasność dla ludzi, ale jednoznaczność dla maszyn. Jedno źródło prawdy, wiele widoków, zero rozbieżności.
To nie koniec. O archetypach, analizie z wykorzystaniem AI i DocForge dowiesz się w kolejnych artykułach i na webinarium.
Zapisz się aby nie przegapić https://www.analizait.pl/webinar-wzorce-projektowe-wspierane-przez-ai/
FAQ: Archetypy biznesowe, Party i AI w modelowaniu domen
Czym jest archetyp Party w modelowaniu biznesowym?
Archetyp Party to jeden z ośmiu fundamentalnych wzorców modelowania domen biznesowych opisanych przez Arlowa i Neustadta, rozwiniętych przez Fowlera. Party opisuje podmiot biorący udział w procesach biznesowych — osobę fizyczną lub organizację — który istnieje niezależnie od jakiegokolwiek procesu. Archetyp Party jest używany m.in. w rozwiązaniu DOcForge do budowania spójnych modeli domen.
Jakie są podtypy archetypu Party?
Archetyp Party ma dokładnie dwa podtypy:
Person – osoba fizyczna
Organization – podmiot prawny niebędący osobą fizyczną
Podmiot nie może należeć do obu podtypów jednocześnie. To ograniczenie wynika z prawa i ma bezpośrednie konsekwencje dla zgodności z RODO.
Czym różni się podmiot (Party) od roli w modelu domeny?
Podmiot (Party) istnieje niezależnie od procesów biznesowych. Rola to kontekst, w którym podmiot uczestniczy w konkretnej transakcji lub relacji. Przykład: Jan Kowalski jest podmiotem (Person). „Klient” to rola, którą pełni w kontekście zamówień. Dane handlowe, takie jak warunki płatności czy limit kredytowy, należą do roli — nie do podmiotu.
Dlaczego podział Person/Organization jest wymagany przez RODO?
RODO (Rozporządzenie 2016/679) stosuje się wyłącznie do osób fizycznych. Dane osobowe to informacje dotyczące zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. NIP firmy nie jest daną osobową. PESEL osoby fizycznej jest. Model danych bez rozróżnienia Person/Organization uniemożliwia precyzyjne stosowanie praw wynikających z RODO: prawa do usunięcia (art. 17), prawa dostępu (art. 15) i prawa do przenoszenia danych (art. 20).
Które rekordy w systemie podlegają RODO jeśli używam archetypu Party?
Wszystkie rekordy z podtypem Person. Archetyp Party pozwala inspektorowi ochrony danych jednoznacznie wskazać zakres danych osobowych w systemie bez analizowania kodu ani przeszukiwania tabel bazy danych.
Jak AI wykorzystuje model domeny z archetypami do generowania kodu?
Gdy model domeny jest zapisany w jednoznacznym formacie – z typami, regułami, stanami i relacjami – AI może go przetworzyć bez interpretowania ani domysłów. Z modelu zawierającego archetyp Party AI generuje: klasy domenowe, schematy baz danych, walidatory i API. Programista otrzymuje działający szkielet do oceny w godziny, a nie tygodnie.
Czym różni się generowanie kodu przez AI z modelu analitycznego od generowania „od zera”?
AI generujące kod bez modelu analitycznego wymyśla strukturę na podstawie opisu w języku naturalnym — interpretuje, zgaduje, może halucynować szczegóły. AI operujące na ustrukturyzowanym modelu z archetypami odczytuje konkretne dane: typy bytów, reguły walidacji, relacje, oznaczenia RODO. Wynik jest przewidywalny i spójny z intencją analityka.
Jak model domeny z archetypami skraca czas tworzenia MVP?
Ustrukturyzowany model analityczny eliminuje etap „tłumaczenia” wymagań biznesowych na decyzje techniczne. AI odczytuje model i generuje prototyp struktury systemu. Programista ocenia i modyfikuje gotowy szkielet zamiast budować go od podstaw. Czas od analizy do działającego prototypu skraca się z tygodni do dni.
