Nastawienie na skalowalność.

Cześć,
Dajmy na to, że spodziewam się mocnego rozwoju formularza oraz mechaniki związanej z jego obsługą.
Chciałbym was zapytać o podejście zaprojektowania rozwiązania nastawionego na zorientowanie obiektowe kosztem redukcji programowania strukturalnego (w sumie jedno wynika z drugiego zgodnie z zasadą asymetrii obiektowośći i struktury).

Na samym początku dajmy na to, że mam 3 pola,
pseudocode:

class Produkt {
int id,
String name;
List<Photo> photos;
}

Przychodzi do nas Pan z biznesu i mówi, fajnie fajnie nasza firma sie rozwija jak akcje redsów przed cp77, to teraz chcemy móc wysyłac nasze produkty za granicę.
Tutaj powstaje pierwsze pytanie, którą drogą pójdziemy by było najlepiej?
Droga 1.
1. Możemy dopisać do klasy Produkt składową Country, ale mamy już działającą infrastrukturę (kontroler. serwisy, baze danych) pod klasę Produkt, więc trzeba będzie pozmieniać.
Co zmieniamy?
Wariant a nasz endpoint. Bedzie teraz odbierał dodatkowo jeden parametr wincyj. Oznacza to, że mamy problem. Z naszej aplikacji korzysta wiele klientów, każdy musiałby zmienić u siebie zapytanie inaczej dostanie 400 Bad Request.
Wariant b Zostawić klasę produkt. Stworzyć nową klasę z Country, zostawić zmapowanie pod stary kontroler oraz oddzielić logikę produktów od produktów wysyłanych poza granice. Takie podejście zaowocuje za jakiś czas dziesiątkami restpointów np. ProductOutboardWithXWithY, więc słabo.

2. Serwisy, każdy serwis będzie miał inną logikę, jeżeli będziemy mieć jedną dużą klasę Produkt, to da się z kontekstu odczytać jej dane oraz znaleźć strategie do obliczenia wysyłki i innych rzeczy np discountów. Co spełnia nasze założenia produkcji kodu w sposób obiektowy.

3. Baza danych, gdzieś trzeba to trzymać.

Droga 2
Problemy podobne co w drodze 1, ale tworzymy jakiś obiekt, który będzie nam Wrappował wcześniejsze obiekty, ale nie wiem jak to zrobić.
Macie jakies pomysł

Wariant a nasz endpoint. Bedzie teraz odbierał dodatkowo jeden parametr wincyj. Oznacza to, że mamy problem. Z naszej aplikacji korzysta wiele klientów, każdy musiałby zmienić u siebie zapytanie inaczej dostanie 400 Bad Request.

Nie rozumiem. Dopisuję do klasy Produkt, w jakimś mapowaniu Country not required, default = Country.PL I się tym nie przejmuję

Droga druga. Robię nową wersję endpointu z wymaganym Country i informuję wszystkich że mają się przepiąć ze starego na nowy (Oni to oczywiście olewają i od tej pory żyję z dwoma endpointami)

W ogóle najpierw to bym się zastanowił, gdzie to Country pasuje domenowo. Czy do produktu rozumianego jako item w jakimś katalogu produktów, czy produkt jako towar do wysyłki. Jeśli na obie rzeczy masz jeden endpoint z produktem, to prawdopodobnie masz tzw. Big Ball of Mud.

Po drugie temat nie ma związku ze skalowalnością aplikacji - temat dotyczy ewolucji modelu i wersjonowania API.

Po trzecie - dołożenie nowego pola nie jest zmianą łamiącą kompatybilność. Dodajesz nowe pole i dodajesz obsługę u klientów.

Ja bym zrobił tak jak @KamilAdam tylko z drobną modyfikacją:

• robią endpoint z default PL
• ogłaszam, że za jakiśtam czas default będzie wyłączony
• zgodnie z ogłoszeniem wyłączam opcjonalność parametru Country
• robi się burdel, dużo zamieszania
• następnym razem czytają moje maile