lugger: сейчас рекомендованный подход по работе с объектами - Object.create. Смиритесь. Через new - старый подход, если вам нельзя использовать ES5. Вопрос совместимости. Благо нынче есть полифилы.
По поводу организационных вопросов - если нельзя повлиять - жаль.
Dartess: внутри ваш же кастыль на jQuery по вызову formatter устанавливает значение (то есть вы в массив должны запихнуть обработчик) и по изменению значения контролом вы должны viewValue установить, и возможно добавить парсер что бы привести значение в нужный вид. Потом и в parsers и в formatters можно запихнуть валидаторы.
Dartess: там все просто. если упростить, есть два варианта значения, modelValue и viewValue. Первый это то что записывается через дата биндинг, второе - значение инпута, которое нужно для отображения. Есть два массива обработчиков - parsers и formatters для преобразования одного в другое. Есть setViewValue или как-то так который нужно дергать когда вы меняете значение своего кастомного инпута.
magary4: это вы так думаете. По факту в половине случаев дальше CRUD сильно логика не будет расползаться. Какие-то базовые штуки можно и там делать. Зато не нужно париться по поводу инфраструктуры и горизонтального масштабирования.
Это нормальное явление - вложить в разработку поменьше в самом начале, и потом, когда будет видно к чему идут дела - делать все уже самостоятельно если текущий выбор уже не удовлетворяет выбранным условиям. Так как на parse.com можно только что-то относительно простое сделать перенести все на свое решение будет не проблема.
К вопросу о SoA и разделении бизнес логики - для каждого приложения выделяется свое ядро, свой спектр задач, свой Core Domain. Если этого сделать не выходит - делить нечего.
OnYourLips: Доктрина позволяет вам работать с обычными PHP объектами без привязки к базе. Именно это позволяет НЕ делать анемичных моделей. Более того, с последней версии доктрины появилась возможность без каких-либо DTO пользоваться всеми прелестями Value object-ов. Лично я использую доктрину именно по этой причине - она никак меня не ограничивает в том, как я буду организовывать слой моделей (я больше не знаю ORM которые позволят организовать настолько просто слой моделей, без DTO).
SoA не диктует разделения бизнес-логики по бандлам. Фактически SoA подразумевает выделение из приложения небольших приложений-сервисов. Это не разделение бизнес логики, а вынесение из приложения всех вторичных вещей. Например можно вынести все что связано с управлением пользователями в отдельное приложение-сервис. Таким образом у нас есть приложение содержащее всю бизнес логику, и не содержащее всякой фигни по тому как у нас хранятся пользователи и т.д. Мы всю эту работу перекладываем на отдельное приложение. Тут так же подходят подходы с мидлварами и т.д. Ну и вся эта катавасия про гексагональную архитектуру об этом.
Бизнес логику вообще крайне странно "делить" и разносить по бандлам. Бандлы нужны для реюза кода (ну и рекомендуется иметь AppBundle содержащий все организации FrameworkLayer (некоторые еще называют это добро как InfrastructureBundle).
OnYourLips: в симфони нет никаких ограничений по тому как и что можно делать. И да, сервисы не выйдут такими уж тонкими. Я больше к тому что бы отказаться от анемичных моделей, что бы не возможно было привести модель к невалидному состоянию. Добавим к этому Domain Events и станет еще лучше.
nadom: проверка введенных слов - отсортированный массив строк и бинарный поиск - норм. Быстро и просто. ПО второму пункту чуть сложнее. Я бы организовал индекс по вхождению символов в строки.
