Автор пишет:
While implementing your domain, you should stop thinking about structs like dummy data structures or “ORM like” entities with a list of setters and getters. You should instead think about them like types with behavior.
И ниже пример: когда вы разговариваете с кем-то про тренировки в тренажерном зале, вам не скажут: "я настроил состояние аттрибута
training schedule на 13:00", вместо этого человек ответит: "я запланировал тренировку на 13:00". Одна из концепций DDD - сделать логику такой же простой и читаемой, а не усложнять ее атрибутами, состояниями и прочими параметрами, которые в большинстве случаев не нужны.
Например, ответом на вопрос "Я могу записаться на тренировку в это время?" может быть или вот такой вот код:
func (s TrainerService) ScheduleTraining(ctx context.Context, request Request) error {
hour, found := s.FindHour(request.Hour)
if request.HasTrainingScheduled && !hour.Available {
//
}
if request.Available && request.HasTrainingScheduled {
//
}
if !request.Available && !request.HasTrainingScheduled {
//
}
}
в котором мы напишем полотно из условий, проверяя те или иные параметры. Или мы можем сделать тип
Hour, для которого описать поведение ScheduleTraining, где мы или получим ошибку что время уже занято, или займем его, если оно доступно:
func (h *Hour) ScheduleTraining() error {
if !h.IsAvailable() {
return ErrHourNotAvailable
}
h.availability = TrainingScheduled
return nil
}
Таким образом внешняя логика, вызывающая этот метод, очень сильно упрощается и становится более читаемой. Более того, такую логику сильно проще покрывать тестами.