Матовый,
Я бы сказал, что ваш магазин пишет процедурный код. Я хочу пояснить, что нет ничего плохого в том, что многие большие системы (включая многие, над которыми я работал) были написаны с использованием процедурного кода. Для этого есть время и место.
Теперь процедурному коду нет места в модели предметной области. Если вы хотите использовать более процедурный стиль, который подойдет, но используйте его с чем-то вроде Table Module или Active Record pattern. Я полагаю, что не столько отсутствие ОО, как это разрушительно в руководстве, но использование модели предметной области с процедурной логикой.
Это приводит к тому, что человек тратит большое количество ресурсов на создание уровня домена (несоответствие импеданса, время мыслительного процесса на создание агрегатов, изоляцию, вездесущий язык и т. Д.) Без получения каких-либо преимуществ, которые в противном случае могли бы получить уровень домена (обычно ремонтопригодность). предоставлять. Другими словами, хотя вы можете выполнять свои функциональные требования просто отлично, вы в конечном итоге тратите большую часть своего бюджета практически без возврата.
Теперь, чтобы вернуться к тому, что такое «поведение», я бы хотел сосредоточиться на вопросе с объектно-ориентированной точки зрения, а не с точки зрения «доменного дизайна». Объект обычно инкапсулирует некоторое состояние и, как правило, демонстрирует некоторые варианты поведения.
быстрое повторение: инкапсулировать состояние, выставлять поведение
Так какое поведение должен иметь объект? Проще говоря, это должно быть поведение, которое воздействует на состояние, которое оно инкапсулирует. В идеальном поведенческом ОО-мире государство никогда не будет подвергаться объектному поведению. Поместите тактически в код, если мы начинаем видеть код как:
Customer c = GetCustomerFromRepository();
c.Status = CustomerStatuses.Deleted;
c.LastUpdated = DateTime.Now;
c.UpdatedBy = GetCurrentUser();
CustomerRepository.Save(c);
У нас есть нарушение SRP ... Этот код является кодом, который должен соответствовать поведению объекта клиента, поскольку "Ответственность" объекта клиента заключается в.
Инкапсулировать информацию о клиенте и раскрыть поведение.
Таким образом, мы видим, что было бы лучше иметь метод Customer.Delete (). (да, это плохой пример, я знаю ...)
Теперь мы бы также достигли этого, используя TDD. Нам гораздо легче иметь дело в тестах со швом, который обеспечивает поведение, чем со швами, где выставлено все состояние. Причина этого в том, что мне не нужно дублировать логику в моих тестах. Код клиента не заботится о том, как работает удаление ... он заботится только о том, чтобы клиент раскрыл поведение. Поэтому в наших тестах вместо того, чтобы утверждать, что c.State == CustomerStates.Deleted и c.UpdatedBy == GetCurrentUser () и т. Д., Мы просто утверждаем, что метод delete был вызван в шве клиента с использованием фиктивного значения.
Теперь вернемся к названию. Количество логики, которая должна присутствовать в бизнес-объекте, - это количество логики, подпадающее под его ответственность за инкапсуляцию его состояния. Иногда это много, иногда нет. Также есть места, где вы хотите использовать сервисы ... хорошим примером была бы координация взаимодействия между многими объектами домена для данного поведения, но даже здесь сервис должен вызывать поведение для объектов домена.
Помогает ли это немного прояснить ситуацию?
Грег