Лучшая практика в отношении инкапсуляции и дизайна с одной ответственностью

Question

Я занимаюсь разработкой уже много лет, и общая проблема, с которой я сталкиваюсь, заключается в том, как лучше выделить уровень обслуживания.В основном я использовал шаблон репозитория, но все еще борюсь с этим распространенным сценарием.

Обслуживание клиентов, которое возвращает одного клиента.Сервис счетов, который возвращает список счетов по клиенту.

Потребитель услуги иногда хочет просто клиента, в противном случае он хочет получить клиента, и счета, которые можно оставить как два вызова.

Но новое требование может заключаться в том, что они хотят, чтобы Клиент, но также хотели иметь общее количество счетов, которое имеет соответствующий клиент.

Я не хочу повреждать метод GetCustomer и не хочу возвращать список счетови пусть они посчитают (это сработает).Есть ли лучшая практика, не вдаваясь в подробности создания одного из методов, при этом имея в виду производительность и циклические туры?Я вижу много проектов, где есть GetCustomer, GetCustomerDeepLoad и т. Д.

спасибо.

Answer 1

Вот почему я перешел на CQRS.Операции (запись / команды) часто нацелены на один тип сущности, в то время как операции чтения (запросы) часто требуют составления сущностей.

Вы не хотите помещать эти запросы в репозитории, так как репозитории, как правило, получают неплотные абстракции, когда высделайте это.

В вашем случае вы можете иметь два типа услуг: службы сущностей, которые отвечают за внесение изменений, и службы запросов, которые отвечают за предоставление информации клиенту (состав различных сущностей).).

Обычно я использую репозитории только на стороне записи и позволяю службам запросов запрашивать базу данных напрямую.Это работает, если ваша бизнес-логика содержится в службах сущностей.

Answer 2

Все просто. Не думай об этом.

Услуги должны отвечать потребностям клиентов. Если клиенту нужны данные о клиенте, служба отправляет представление сведений о клиенте и ничего более; если клиент хочет клиента и все его заказы, услуга обязывает; и так далее. При этом вам может потребоваться нечто большее, чем просто Customer объект; например, вам может понадобиться объект CustomerOrderList, состоящий из CustomerOrderItem и т. д.

То, что вы НЕ ДОЛЖНЫ делать, - это смешивать проблемы управления заказами и управления клиентами, что означает, что возвращаемая вами CustomerOrderItem будет версией, подходящей для управления клиентами, а не полноценной OrderItem, которая будет смоделирована для управление заказами.