Владимир Грабко: избавьтесь от types и вообще пусть для валидации email и валидации login будут отдельные функции. Ну и дублирование выносите в другие функции и т.д.
Грубо говоря,,, validateEmail, validateLogin, isEmailAvailable, isLoginAvailable и т.д.
Владимир Грабко: вы поймите, главное что бы ваш код читался и менялся удобно. Код намного чаще читают чем пишут, так что вы должны сделать все возможное что бы время уходящее на то что бы прочитать код и разобраться что он делает было минимальным. Иначе потом люди будут тратить по пол часа на код который вы написали за 5 минут, согласитесь, это не очень продуктивно.
Виктория: ну представьте себе мобильное приложение написанное на Java или на Objective-C. Или десктопное приложение. Ну вот как-то так. Полноценное приложение, точка входа в которое одно - index.html, а далее все разруливается джаваскриптами.
Что до JSPM, bower по сути умер, там только один активный контрибьютор, и это грустно. У JSPM как-то динамичнее с развитием, да и он ориентирован на модульный JS, тогда как bower ориентирован только на управление ассетами.
Константин Китманов: я пока забил на system.js... попробовал webpack... я за два часа с ним сделал то же что пытался пару дней сделать на system.js. В итоге расстроился и пока забил на jspm+system.js
Константин Китманов: надо стремиться к тесты есть а кода нет, ибо к готовому коду намного ленивей тесты писать и они теряют добрую половину своей практической ценности).
Хорошая архитектура - это очень понятная архитектура
Хорошая архитектура - это когда можно легко вносить изменения, когда можно откладывать принятие важных решений (например какую базу данных использовать). То что она понятная и т.д. это побочный эффект. То есть если приложение легко изменять и тестировать, если у нас низкая связанность между компонентами, то она становится понятной.
Всего существует не так много типов задач:
Ваша классификация весьма спорна, если вы не против я чуть чуть поворчу.
1) В частности про модель, она отвечает за хранение данных но она ничего не должна знать о том как данные хранятся. Противоречие. Вообще вопрос что вы под моделью понимаете. Модель предметной области? Это вся бизнес логика приложения, и тогда она не должна знать что там где хранится. По сути привнося термин "модель" в такой краткой формулировке вы только забиваете голову людям ерундой. Из вашего описания я подозреваю что под моделью вы подразумеваете сущности, отдельные бизнес объекты.
2) тут все ок, но и не ок. Репозиторий это шаблон проектирования. Реализации репозиториев это так же сервисы. Репозиторий должен работать только с одной сущностью, обычно это корень агрегата, но тогда все становится сложнее.
3) бизнес логика - опять же это да, сервисы.... но сервисы это вообще все что крутится у нас в контейнере зависимостей. Сервисы могут пренадлежать как слою бизнес логики так и слою представления, слою организации хранилищ и т.д. Это просто код.
4) тут лучше сказать что сервисные штуки, инфраструктура, должна быть отделена от бизнес логики. А вещи типа кеширования проще добавлять декорацией репозиториев или других сервисов.
5) а если отображение данных у нас JSON? тоже шаблоны? Вообще-то всякие фильтры для твига это тоже относится к view layer, это не только шаблоны, но и шаблонизаторы, и различные утилитки и хелперы, фильтры и расширения... много чего.
6) в идеале контроллер должен преобразовать запрос пользователя из формата интерфейса (http) в формат приложения (dto, команды, etc) и передать в сервис. Причем в один сервис. То есть хорошо будет если у нас контроллер на каждый экшен будет делать ровно один вызов ровно одного метода ровно одного сервиса. Все что больше - уже не так хорошо, но можно. Просто так мы делаем контроллеры толще. Это дает нам возможность протестировать всю бизнес логику связанную с этим конкретным действием без необходимости поднимать всю инфраструктуру.
Сервисы "кеширования" ложить в папку persistence как-то нелогично, кеш не относится к persistence layer, это же кэш. Лучше сделать Infrastructure/Cache или еще как. А лучше просто положить рядом с декорируемым сервисом декоратор, например FooRepositoryCache.
Если в хорошей архитектуре изменится структура базы данных, то это либо скажется на бизнес объектах либо не скажется. Вообще все намного сложнее чем вы описали.
Ну и опять же, вы описываете что "анемичная модель это ок", что я сичтаю неправильным.
Грубо говоря,,, validateEmail, validateLogin, isEmailAvailable, isLoginAvailable и т.д.