Разделение услуг -> Бизнес-объекты?

Question

Я верю, что структурирую свои проекты, как это делают многие.У вас есть уровень данных (DAO), уровень обслуживания (службы) и уровень представления (Spring MVC, Wicket, ...).

Обычно служба начинает быть довольно простой и «короткой».Однако постепенно служба должна поддерживать все больше и больше вариантов использования, пока через некоторое время она не станет одним огромным классом с множеством строк и методов, и ее будет трудно читать и поддерживать.В это время вы можете либо решить придерживаться этого, либо начать рефакторинг, что является громоздкой и «опасной» работой, которая может занять много работы.

Я ищу решение для предотвращения необходимости какого-либо рефакторинга в будущем.
Одним из подходов может быть разделение ваших услуг на несколько подуслуг и превращение вашей первоначальной услуги в фасад службы.Так, например, вместо большого UserService у вас может быть UserServiceFacade, который делегирует вызовы PasswordService, RegistrationService, ....

Я думаю, это неплохое решение, но я не слишком восторженно к этому отношусьпотому что:

1. сложно заранее определить, на какие подслуги разделить работу;если вы ошиблись, вам все равно может понадобиться рефакторинг в обратном направлении или у вас может быть служба только с одним методом, например
2. повторное использование бизнес-логики может быть более сложным, если, например, PasswordService и RegistrationService требуется общая функциональность

Другим решением может быть использование бизнес-объектов, которые (в моем понимании) также можно увидеть как вспомогательные сервисы, но затем по одному для каждого конкретного UseCase, так что у вас могут быть BO, такие как CreateUserBO, CheckPasswordBO, DeleteUserBO, ....

Я немного более восторженно отношусь к этому подходу, потому что, по моему мнению, он предлагает довольно много преимуществ:

1. Сам BO очень читабелен и требует только от своего контракта;все остальное можно делегировать другим BO, один BO будет коротким и к точке
2. Простота повторного использования функциональности
3. Легче изменить / переключить реализацию определенного UseCase: просто ввестидругая реализация с Spring
4. Проще протестировать: нужно тестировать только для конкретного UseCase, делегировать другим BO можно смоделировать
5. Сотрудничество: меньше конфликтов, если несколько разработчиков работают над разными BO, тогда, когда они работаютна том же сервисе

Однако я также вижу некоторые возможные недостатки:

1. немного дополнительной работы (по крайней мере, в плане сортировки)
2. Многоебольше классов, которые могут снизить читабельность вашего проекта?
3. еще один уровень абстракции: требуется дополнительный шаг, чтобы найти фактическую реализацию UseCase

Вопрос или, скорее, вопросы (извините) являются:

1. Являются ли Business Objects идеальным решением для этой проблемы?
2. Согласны ли вы с преимуществомs / недостатки BO, которые я перечислю выше и / или вы видите других?
3. Существуют ли другие (хорошие) решения для предотвращения мега-услуг, разрушающих ваш день?

Answer 1

Я бы порекомендовал вам взглянуть на эту статью на Domain Driven Design , если ваше заявление представляет собой нечто серьезное, чем задание колледжа.Основная предпосылка - структурировать все вокруг ваших сущностей и иметь сильную модель предметной области.Различайте сервисы, предоставляющие услуги, связанные с инфраструктурой (такие как отправка электронной почты, постоянные данные), и сервисы, которые действительно выполняют ваши основные бизнес-требования.

Я бы также предложил изучить Spring Roo -что привносит некоторые революционные вещи в то, что касается создания слоев, например, отсутствие необходимости в слоях DAO и т. д.

Надеюсь, это поможет.

Answer 2

Что я лично делаю, так это то, что я всегда использую фасад для своих услуг.Логика находится во внутренних классах службы, но я предоставляю интерфейс, который может вызывать клиент этой службы.

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

Так что, даже если у вашего сервиса много функций, фасад вполне обслуживаем.

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

Answer 3

При первом подходе, который вы упоминаете, вместо создания «фасада», почему бы просто не расширить этот сервис?В такой ситуации вы сможете повторно использовать код из супер / оригинального класса.

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

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