Блог

Допустим, мы хотим создать какую-то систему, подобную бронированию билетов (бронирование билетов здесь не главное, это просто пример)

Итак, у нас есть класс User, класс Ticket и т. Д

У нас также есть класс TicketService, который предоставляет методы для bookTicket(), cancelTicket() и т.д. и т.п.

На диаграмме классов TicketService должен быть включен или нет?

Если нет, то где должны отображаться bookTicket() или cancelTicket() на диаграмме классов, в классе Ticket или классе User (поскольку пользователь создает ticket)

Это зависит от того, что вы хотите представить. Если вам нужно точное представление вашего кода на диаграмме классов, то да; если вы просто хотите объяснить логику своего бизнес-домена (т. Е. Бизнес-объектов в домене), и вы не хотите беспорядка, тогда нет, вы могли бы отказаться от класса service. Это субъективно / основано на мнениях и зависит от того, что вам нужно сделать.

Если вы хотите избежать класса обслуживания, но вы хотите представить логику домена с поведением, тогда вы могли бы просто добавить операции «book ()» и «cancel ()» в класс Ticket. Это был бы стандартный подход в объектной ориентации — т. Е. инкапсуляция поведения (и данных) внутри объекта, который за это отвечает.