Rozdziały przewodnika
Decyzje odwracalne i nieodwracalne
Problem#
Większość decyzji przy budowie marketplace jest odwracalna i nie warto się nad nimi zastanawiać dłużej niż chwilę. Kilkanaście nie jest, i to one decydują, czy za dwa lata rozwijasz system, czy go przepisujesz.
Ten rozdział jest listą tych kilkunastu, zebraną z poprzednich rozdziałów w jednym miejscu.
Tanie do dodania później#
Dla tych rzeczy nie warto planować z góry. Kosztują tyle samo dziś i za rok.
- Kolejne pola w profilu sprzedawcy i produktu.
- Filtry, wyszukiwanie i widoki w panelu.
- Nowe szablony powiadomień i kanały.
- Kolejne metody wysyłki i progi darmowej dostawy.
- Kolejni dostawcy integracji, jeśli pierwszy trafił do wspólnej warstwy.
- Role i uprawnienia, dopóki izolacja danych jest w warstwie dostępu.
Drogie do wycofania#
| Decyzja | Koszt późnej zmiany | Rozdział |
|---|---|---|
| Zamówienie ma jednego sprzedawcę | migracja wszystkich zamówień historycznych | 1, 6, 7 |
| Produkt ma jeden wariant | migracja cen, stanów i pozycji zamówień | 3 |
| Stan magazynowy bez wymiaru lokalizacji | migracja stanów i otwartych rezerwacji | 5 |
| Brak identyfikatora zewnętrznego | ponowne dopasowanie zaimportowanych pozycji | 3, 4 |
| Wartości liczone przy odczycie | raporty historyczne zmieniają wyniki | 6, 9, 11 |
| Prowizja jako odwołanie do reguły | zmiana stawki przepisuje przeszłość | 11 |
| Anulowanie tylko całego zamówienia | przeliczenie wartości i podatków w historii | 7, 13 |
| Wypłata bez powiązania z zamówieniami | brak drogi powrotnej dla zwrotu | 10, 13 |
| Izolacja danych w widoku | przegląd wszystkich ścieżek dostępu | 15, 17 |
| Brak identyfikatora operacji | nie da się odtworzyć tego, co już zaszło | 16 |
Niebezpieczne założenia#
To nie są decyzje, tylko przekonania, które wchodzą do kodu niezauważone.
| Założenie | Prostsza bezpieczna alternatywa |
|---|---|
| Zamówienie zawsze ma jednego sprzedawcę | sprzedawca przy linii, nie przy zamówieniu |
| Prowizja zawsze będzie jedna | zapis naliczonej kwoty przy pozycji |
| Produkt platformy i produkt zewnętrzny to jedno | osobny identyfikator z oznaczeniem źródła |
| Udana płatność znaczy udane zamówienie | dwa zdarzenia i sposób wykrycia rozbieżności |
| Sprzedawca nigdy nie podepnie sklepu | miejsce na identyfikator zewnętrzny |
| Bieżący profil sprzedawcy zawsze wystarczy | snapshot danych widocznych przy zamówieniu |
| Żywy rekord opisze stan historyczny | utrwalenie wartości w chwili zdarzenia |
Jak z tego korzystać#
Przed każdą decyzją o modelu danych zadaj trzy pytania. Jeżeli odpowiedź na którekolwiek brzmi tak, decyzja należy do drugiej kategorii i warto poświęcić jej godzinę zamiast minuty.
- Czy na tej wartości opierają się zapisy historyczne?
- Czy zmiana wymusiłaby przeliczenie danych, których nie wolno przeliczać?
- Czy odwrotny kierunek zmiany jest darmowy?
Trzecie pytanie jest najbardziej praktyczne. Przejście z modelu ogólniejszego na węższy prawie zawsze jest darmowe, a z węższego na ogólniejszy prawie nigdy. Dlatego przy wątpliwości wybiera się ogólniejszy, o ile nie kosztuje dziś realnej pracy.
Co się sprawdza w praktyce#
Poprawki, które kosztowały mnie najwięcej, dotyczyły kształtu danych, a nie brakujących funkcji. Funkcję dopisuje się obok istniejących danych. Zmiana tego, jak dane są ułożone, dotyka wszystkiego, co już zostało na nich zapisane.
Checklista#
- Znasz listę decyzji, które w Twoim projekcie należą do drugiej kategorii.
- Dla każdej z nich wybrałeś wariant ogólniejszy albo świadomie odrzuciłeś.
- Żadna wartość używana w rozliczeniach nie jest liczona przy odczycie.
- Żadne założenie z ostatniej tabeli nie jest zaszyte w kodzie bez decyzji.
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace