Model marketplace przed funkcjami

Problem#

Najczęstszy błąd przy budowie marketplace nie jest błędem technicznym. Polega na tym, że katalog, koszyk i płatności powstają, zanim ktokolwiek rozstrzygnie, kto właściwie sprzedaje, kto przyjmuje pieniądze, kto wysyła i kto odpowiada za reklamację.

Te odpowiedzi nie są ustawieniem w konfiguracji. Wchodzą w model danych i zostają tam na lata. Zmiana którejkolwiek z nich po starcie oznacza migrację zamówień, płatności i historii, czyli dokładnie tych danych, których nie wolno zgubić.

Sześć decyzji, które zapadają na początku#

Minimalna wersja#

Na start wystarczy rozstrzygnięcie sześciu decyzji powyżej, zapisane w dokumencie i odzwierciedlone w modelu danych. Nie potrzebujesz do tego żadnego kodu poza tym, żeby encje wiedziały, kto jest właścicielem czego.

• Każda linia zamówienia zna swojego sprzedawcę, nawet jeśli dziś zamówienie ma zawsze jednego.
• Produkt zna sprzedawcę, który go wystawił.
• Stan magazynowy zna właściciela, nie tylko produkt.
• Płatność zna podział na sprzedawców, nawet gdy podział jest jednoelementowy.

Czego nie budować teraz#

• Konfiguratora modelu biznesowego. Wybierasz jeden model, nie budujesz platformy obsługującej wszystkie.
• Abstrakcji nad dostawcą płatności, zanim masz drugiego dostawcę.
• Własnego katalogu kanonicznego z deduplikacją ofert, dopóki nie ma realnego problemu z duplikatami.
• Obsługi wielu magazynów, dopóki wysyła sprzedawca.

Zaplanuj z góry#

Trzy rzeczy są tanie teraz i kosztowne później, niezależnie od wybranego modelu.

Własność na poziomie linii, nie zamówienia#

Zamówienie może dziś mieć jednego sprzedawcę. Model danych nie musi tego zakładać. Przypisanie sprzedawcy do linii zamówienia jest neutralne dla wersji jednosprzedawcowej i wystarczające dla wielosprzedawcowej.

Snapshot zamiast referencji dla danych transakcyjnych#

Tytuł produktu, cena, stawka prowizji i dane sprzedawcy widoczne dla kupującego mają zostać zapisane w momencie zakupu. Odczytywanie ich później z żywych rekordów oznacza, że historyczne zamówienie zmienia się razem z katalogiem.

Identyfikator zewnętrzny osobno od własnego#

Jeżeli istnieje choćby plan podpięcia sklepów sprzedawców, produkt potrzebuje miejsca na identyfikator z systemu źródłowego, oddzielnego od własnego identyfikatora. Doklejenie tego później do pola ogólnego przeznaczenia działa, ale mapowanie i wykrywanie konfliktów stają się zgadywanką.

Wyzwalacze#

Konkretne zdarzenia, po których wracasz do decyzji z tego rozdziału:

• kupujący pierwszy raz pyta, dlaczego musi złożyć dwa osobne zamówienia;
• pierwszy sprzedawca pyta, czy może wystawiać towar ze swojego sklepu;
• pierwsza reklamacja, przy której nie wiadomo, kto ma ją rozpatrzyć;
• pierwszy zwrot po wypłacie pieniędzy sprzedawcy;
• druga osoba zaczyna podejmować decyzje operacyjne.

Częste błędy#

Co się sprawdza w praktyce#

Decyzją o największych konsekwencjach w systemie, który prowadzę na produkcji, okazało się przypisanie sprzedawcy do linii zamówienia, a nie do zamówienia. Ta jedna relacja przesądziła później o kształcie podziału płatności, rozliczeń, zwrotów i wypłat, a każdy z tych modułów powstawał znacznie później niż sam katalog.

Drugą taką decyzją był snapshot danych rozliczeniowych w momencie zakupu. Bez niego każda zmiana stawki prowizji albo ceny produktu zmieniałaby wstecz wartość rozliczeń, których nie wolno ruszać.

Checklista#

• Wiadomo, kto jest sprzedawcą wobec kupującego, i widać to w interfejsie.
• Linia zamówienia zna swojego sprzedawcę, niezależnie od dzisiejszego modelu koszyka.
• Dane potrzebne do rozliczenia są zapisywane w momencie zakupu, a nie odczytywane później.
• Produkt ma miejsce na identyfikator z systemu zewnętrznego.
• Wiadomo, kto rozpatruje reklamację, zanim wpłynie pierwsza.
• Żadna z sześciu decyzji nie jest odłożona do "ustalimy przy okazji".