У меня действительно проблема с проверкой и программированием бизнес-правил (дизайн) в стандартной архитектуре приложения Spring (контроллер -> служба -> DAO ...).
Побитно, уровень обслуживания классы перегружаются уродливыми if-s , наивными рефакторированными методами, которые объединяют некоторые общие проверки на уровне класса и т. Д. Просто все это требует еще одна практика рефакторинга, чтобы сделать код более понятным.
Я знаю, что такое системы управления бизнес-правилами и тому подобное, например Hibernate Validator, но я не хочу использовать сторонние решения, если это возможно .
Недавно я прочитал о Шаблон проектирования и спецификации драйвера домена выглядит привлекательным решением для организации бизнес-правил. Я также читал разные мнения о комбинации Spring и DDD.
Поскольку я новичок, возможно, моя идея будет выглядеть наивной, но я подумывал объединить возможности AOP Spring Framework и шаблона спецификации в качестве удобного подхода для формулирования бизнес-правил и логика. В этой комбинации АОП будет использоваться только для вставки конкретного бизнес-правила в конкретный метод обслуживания. В качестве некоторого расширения я подумал, что, возможно, Шаблон стратегии поможет определить различные стратегии проверки.
Но возникает много вопросов. Как изменить стратегию в соответствии с контекстом проверки, взрывом номера класса, чрезмерным использованием шаблона и т. Д.
Я просто хочу услышать некоторые мысли об этой идее и советы об упомянутой проблеме. Спасибо