Co definiuje dzień?
Programiści często skupiają się na niewłaściwych rzeczach podczas budowania nowych funkcji.
Możesz myśleć o danych backendowych, duplikacji kodu lub wydajności. Te kwestie są istotne. Ale nie są to najważniejsze pytania.
Często popełniam ten błąd. Ekscytuję się inteligentnymi wzorcami i czystym kodem. Zaczynam pisać kod, zanim w pełni zrozumiem, jak użytkownik korzysta z danej funkcji. Wtedy uświadamiam sobie, że mój kod nie odpowiada celowi biznesowemu.
Weźmy za przykład aplikację kalendarza.
Użytkownik klika w 1 marca, aby zaznaczyć święto. Ale aplikacja zamiast tego zaznacza 28 lutego. Dzieje się tak z powodu stref czasowych.
Programista użył obiektu Date. Obiekt Date reprezentuje konkretny moment w czasie.
W Tokio północ 1 marca to wciąż 28 lutego w Londynie. Jeśli Twój kod używa metod UTC do zapisywania daty, dzień ulega przesunięciu.
Błąd istnieje, ponieważ implementacja techniczna przeczy logice biznesowej.
Użytkownik myśli dniami. Użytkownik nie myśli przesunięciami UTC ani znacznikami czasu w milisekundach. Myśli: „Chcę 14 marca”.
Jeśli chcesz, aby Twój kod był niezawodny, musisz poprawnie modelować domenę.
W papierowym kalendarzu data to po prostu rok, miesiąc i dzień. Nie ma ona strefy czasowej.
Możesz naprawić ten błąd, zachowując spójność z czasem UTC lub lokalnym. Ale to tylko rozwiązanie tymczasowe. Lepszym sposobem jest użycie struktur danych, które nie mogą zawieść.
Zamiast obiektu Date, użyj własnego obiektu:
• Rok: 2026 • Miesiąc: Marzec • Dzień: 1
To usuwa czas i strefy czasowe z równania. Sprawia, że błąd staje się niemożliwy.
Tak, wymaga to więcej pracy. Musisz napisać narzędzia pomocnicze do porównywania dat lub znajdowania końca miesiąca. Masz terminy i sprinty, o które musisz dbać.
Ale poprawne modelowanie domeny chroni Cię przed wściekłymi zgłoszeniami do wsparcia i godzinami debugowania w przyszłości.
Jak mówi Eric Evans w Domain-Driven Design:
„Aby komunikować się skutecznie, kod musi opierać się na tym samym języku, którego użyto do sformułowania wymagań”.
Przestań myśleć tylko jak programista. Zacznij myśleć o regułach biznesowych.