Modelowanie ogłoszenia o pracę w kontekście kilku możliwości

Hej, mam problem z pewnym modelem. Pisze w Javie ale problem nie dotyczy języka. Mam klasę Job która reprezentuje ogłoszenie o pracę i mam problem z zamodelowaniem kwestii rodzaju umowy oraz wypłaty. Możliwości jest kilka i przedstawię tylko część (pomijam w tym przypadku wszystkie kwestie prawne). Jeśli wybierzemy umowę o dzieło to wypłata powinna być za wykonaną pracę a stawką jest kwota za wykonanie dzieła (np. 500zł). Jeśli wybierzemy zlecenie to pracodawca może wybrać wypłatę za wykonanie zlecenia lub też stawkę godzinową. Jak to teraz zamodelować? Umowa o pracę też może mieć obie możliwości. Aktualnie mam klasę Job która ma wszystkie informacje typu contactPerson, details itd i to są informacje spójne dla wszystkich więc moim zdaniem jest okej, natomiast mam też pole contractType oraz obiekt klasy Salary w którym mam zdefiniowane wszystkie możliwości, mniej więcej coś takiego:

class Salary {

        private String salaryType; //Wypłata za godzinę pracy czy za całość zlecenia

        private BigDecimal salaryPerHourNet; //Dla wypłaty godzinowej
        private BigDecimal salaryPerHourGross; //Dla wypłaty godzinowej
        private String workingTime; //Dla wypłaty godzinowej
        private String workingTimeUnit; //Dla wypłaty godzinowej

        private BigDecimal salaryNet; //Dla wypłaty za całość zlecenia
        private BigDecimal salaryGross; //Dla wypłaty za całość zlecenia

    }

Pod względem funkcjonalnym to działa bo mając Mongo zapisuje tylko te pola które są wypełnione więc żadnych nulli po stronie bazy nie mam, natomiast wydaje mi się to jakieś mega głupie. Taka kombinacja wszystkiego ze wszystkim. Podobnie wygląda to w DTO z formularza który przychodzi ale tam w pewnym sensie wydaje mi się że jest to okej bo nie wiem czego się spodziewać od osoby która wypełnia formularz, natomiast później w domenie mam wrażenie że można to zrobić znacznie lepiej.
Ktoś ma jakąś lepszą propozycję?

Nulle bedą przy odczycie, bo jako że nie ma pól to do pamięci pójdą nulle, wiec to że nie ma ich w bazie to IMHO żodyn argument. Widziałbym to na dwa sposoby - turboprosty, czyli podana kwota brutto za miesiąc i zależności od typu umowy jakiś sposób przeliczania tego (lub nie), albo zastosować dziedziczenie tzn jest klasa bazowa czyli typ umowy, umowa, cokolwiek i ona ma wszystkie te pola, ale także metody zwracające boolean np. 'czy zawiera stawkę godzinową', więc klasa implementująca dla umowy o prace może tam zwracać wyjątek gdy zapytasz ją o stawkę godzinową.

Hmm, skoro to ogłoszenie o pracę to model wydaje się bardzo prosty.

To może coś mega prostego do opisu Salary:

• kwota od (jako Money, bo waluta też się pewnie przyda)
• kwota do (j.w.)
• rodzaj płatności (godzina, dzien, tydzien, miesiąc, całość)
• forma umowy: dzielo, uop, b2b, zlecenie

W takim ogłoszeniu o pracę pewnie będziesz miał kilka przypadków użycia:

• stworzenie ogłoszenia
• aktualizacja ogłoszenia
• publikacja ogłoszenia

Po co te workingTIme i workingUnit i salaryNet i Gross? Gross będzie zależało od aktualnych regulacji prawnych dotyczących podatków.
W systemie możesz dać możliwość edycji słowników: RodzajPlatnosci i FormaUmowy (żeby nie trzeba bylo przepisywać systemu jak pojawi się nowy rodzaj umowy, albo np. płatność kwartalna).

Trochę średnio z czasem, bo sporo pracy w robocie, ale tak na szybko to pomyślałbym o politykach z DDD i tak spróbował zamodelować - czyli po prostu wzorzec strategii i jakieś fabryki. Zrobiłbym jakiegoś dtosa z polami: typ zlecenia, typ wypłaty, salary i godziny, gdzie to ostatnie jest nullable, następnie wstrzyknął taki obiekt do fabryki, która wyprodukuje Ci odpowiednią politykę naliczania wypłaty (calculateSalary()) i sobie użyjesz tego gdzieś. Ale będę w domu to ogarnę to może sensowniej.

hcubyc napisał(a):

Nulle bedą przy odczycie, bo jako że nie ma pól to do pamięci pójdą nulle, wiec to że nie ma ich w bazie to IMHO żodyn argument.

Nie patrzyłem na to w ten sposób ale oczywiście zgadzam się bardzo.

hcubyc napisał(a):

Widziałbym to na dwa sposoby - turboprosty, czyli podana kwota brutto za miesiąc i zależności od typu umowy jakiś sposób przeliczania tego (lub nie),

Trochę to średnie bo skupiam się na tym że mogą to być prace dorywcze a tam bardzo często stawka jest godzinowa. Chciałbym więc dać możliwość dowolnego formatu wprowadzania wynagrodzenia.

hcubyc napisał(a):

albo zastosować dziedziczenie tzn jest klasa bazowa czyli typ umowy, umowa, cokolwiek i ona ma wszystkie te pola, ale także metody zwracające boolean np. 'czy zawiera stawkę godzinową', więc klasa implementująca dla umowy o prace może tam zwracać wyjątek gdy zapytasz ją o stawkę godzinową.

Tak średnio bym powiedział bo tu nie chodzi o to że to rodzaj umowy definiuje rodzaj wynagrodzenia tylko użytkownik. To znaczy że np. dla umowy zlecenia możliwe jest wprowadzenie wymagrodzenia godzinowego albo też pełnego za wykonaną pracę.

yarel napisał(a):

To może coś mega prostego do opisu Salary:

• kwota od (jako Money, bo waluta też się pewnie przyda)
• kwota do (j.w.)
• rodzaj płatności (godzina, dzien, tydzien, miesiąc, całość)
• forma umowy: dzielo, uop, b2b, zlecenie

Hmm... No w sumie to ma nawet sens. Zobaczymy czy uda się coś ciekawego jeszcze wypracować w tym temacie ale jeśli nie to spróbuję w tę stronę.

yarel napisał(a):

Po co te workingTIme i workingUnit i salaryNet i Gross? Gross będzie zależało od aktualnych regulacji prawnych dotyczących podatków.

Doszedłem do wniosku że jeśli użytkownik poda kwotę netto to będę sam liczył kwotę brutto i zapisywał ją w bazie (i odwrotnie). Na czas widoczności takiego ogłoszenia obowiązują takie i takie przepisy w oparciu o które wykonywana byłaby kalkulacja. Jeśli ogłoszenie byłoby już nieaktualne a przepisy zostałyby zmienione to wówczas mam zapisane kwoty jakie na tamten czas obowiązywały. Chociaż jak teraz to piszę to sam nie czuję się przekonany żeby to miało sens więc chyba faktycznie warto to poprawić ;) Dodatkowo gdyby przepisy się zmieniły w czasie trwania ogłoszeń to już miałbym błędne wartości zapisane... Masz rację, do poprawy.

Dlaczego nie chcesz mieć wielu implementacji interfejsu Salary w zależności od formy zatrudnienia?

class UopSalary { 
        private BigDecimal salaryPerHourNet;
        private BigDecimal salaryPerHourGross;
        private String workingTime;
        private String workingTimeUnit;
 }

class ZlecenieSalary {
        private BigDecimal salaryNet;
        private BigDecimal salaryGross;
 }

PS: Nie wiem jak formy zatrudnienia się tłumaczą =(