Repository или CQRS?
Вот так всегда, очаровались красивой идеей, где-то что-то понравилось, руки чешутся применить... А нужно оно или не нужно... Отталкивайтесь от того, что хотите сделать, а Вы об этом так и не рассказали, и уже потом можно переходить к тому, какую парадигму выбрать, потом выбирать паттерны, фреймворки, библиотеки (но лучше как можно меньше их конечно). Вот для чего Вам CQRS? Что он будет решать и почему без него не лучше? Вы не сможете ответить на эти вопросы если не будете идти от задачи. А потом так и выходит: "что не напишу - все контроллер выходит, это наверно потому, что я все время думаю о контроллерах" )))
Добрый день!
Честно говоря, не знаю, что именно Вам понравилось в CQRS и EventSourcing. На мой взгляд, это слишком сложный, непривычный подход, который может использоваться в исключительно редких случаях (как сказал Тимур Шемсединов, все зависит от задачи). Подходы к проектированию приложения нужно применять не тогда, когда они нравятся, а тогда, когда нужно решить конкретную проблему. Если при разработке приложений всегда делать "всякие такие интересные штуки", то процесс разработки уйдет в бесконечность... Проектируйте по принципу: есть задача - как лучше (под "лучше" я понимаю: просто, эффективно, быстро) ее решить. Всё. Если проект "исключительно" в целях обучения - то пожалуйста, здесь Вы вольны использовать всё, что душе угодно. Но если проект реальный, и он Вас "кормит", то тут следует сдерживать свое рвение к новым подходам и всегда задавать вопрос: эта технология/паттерн/механизм/подход поможет решить мне эту задачу? Да - значит, берем, учим, используем, внедряем. Нет - значит, нафиг. Потом больше геморроя будет с сопровождением и изменением кода (и думайте всегда о том разработчике, которому достанется Ваш код после Вас).