Piszę prostą apkę czatu do spotkań której szczegółowe zasady działania nie są istotne, najważniejsza to taka, że aby spotkanie mogło się rozpocząć to muszą dołączyć 4 osoby i nie mogą się one zmienić.
Zastanawiam się jak zamodelować domenę w tym przypadku. Widze 2 podejścia.
- Tworzę klasę Meeting w ktorej ustawiam sobie jakąś nazwę spotkania + hasło (te pola mogą być niemutowalne bo nie da się ich zmienić) i na podstawie tych danych pozostali członkowie mogą dołączać do spotkania (+ kilka dodatkowych pól które są ustawiane na podstawie dołączających osób) i te pola niestety muszą być mutowalne bo będą się zmieniać/ustawiać w trakcie dołączania kolejnych osób.
- Tworzę klasę np. PreMeeting która ma tak jak wyżej pisałem nazwę + hasło niemutowalne a pozostałe pola mutowalne. Kiedy wszyscy dołączą i spotkanie może się rozpocząć to tworzony jest obiekt z klasy Meeting który budowany jest na podstawie PreMeeting i dzięki temu wszystko tam może być niemutowalne. Dalsza logika opiera się już na działaniu na tym obiekcie.
Co myślicie? Co ma większy sens? Wydaje mi się że drugie rozwiązanie ale z drugiej strony zastanawiam się czy to nie jest overkill chociaż przypominam sobie jakaś prezentacje Jakuba Nabrdalika w której mówił o modelu artykułów w Allegro i rozwiązanie tam było podobne. Na początku tworzony jest DraftArticle i jak zostanie wszystko przygotowane jak należy to dopiero na tej podstawie tworzony jest konkretny obiekt z klasy Article.