Я так понимаю, вы решаете проблему автоматического подписания документов?
Какие выдели варианты?
Я пробовал решить с помщью сервиса paperless. Но там нельзя подписать автоматически сгенерированный документ.
Ну, я не люблю вещи из серии "просто работает". Оверхед или нет - это уже мой головняк. Я готов переплатить\переработать, но разобраться. Кроме того, следующему человеку, кто будет копать в эту сторону, я смогу дать ясный ответ.
А откуда ты это знаешь, что боты так будут ходить? В смысле, может так оно и есть, но мне очень помогут доказательства. Что мешает ботам отследить onclick и сделать POST? НА сколько я знаю, они так умеют, по крайней мере у гугла JS хавают. А если не хавают - то тогда и моя версия с pjax будет работать, т.к. синхронно отдаётся такой контент, как при прямом GET запросе ссылки, а при onclick добавляется параметр _pjax и по той же ссылки уже только нужный контент грузится. За идею отличать pjax запрос через метод - спасибо. Но я вот подумал... Если только ради отличия типа запроса - нет смысла, т.к. можно проверять на XHR. Смысл имеется только с условием, что боты принципиально игнорят POST. Хотя, коментарии же боты не отправляют... Может ты и прав тогда. Но в любом случае получить бы пруфы, что боты нормально отнесутся к тому, что я им один метод сую, а юзеру - другой.
Да понял я, что ты имеешь ввиду. НЕ понял - как это связано с моим вопросом. Как это поможет? Ну, загрузил я через POST. Это хоть на один из моих вопросов отвечает? В любом случае, спасибо тебе, что участвуешь. Это без сарказма.
Звучит, как какая-то реклама. "У тебя проблемы с самооценкой? Тебя не уважают поисковики? Боишься параметра?- Избавься от него раз и навсегда! С нашим новым средством profesor08 возможно всё! Через GET загружай все, через POST только часть. Скажи НЕТ страху параметров!"
А вообще, я не понял - к чему это. Я как раз решаю проблему, как через GET загружать часть. Как то переборю страх.
Разве pjax не попадает под ssr? Server Side Rendering имеете ввиду? Именно на сервере у меня и происходит рендеринг блока с учотом состояния. Или сср - обязательно рендеринг всего сайта на сервере? В любом случае, почитаю по теме, спасибо.
Подскажите, что делать с обновлением метатегов при ajax\pjax запросе? Есть опыт решения такой проблемы?
pushState меня обнадёживает в плане описанной проблемы. Т.е. ссылку то мы поменяем. А вот что делать с метатегами - вопрос непонятный. Есть идеи? search console ответит на этот вопрос? Кстати, спасибо за совет.
У поисковиков есть range brain, который больше людей понимает. Но это не значит, что поверх него не используются некоторые фильтры, которые... Ну, всякое могут. Я просто не осведомлён в деталях.
Похвастайтесь системой, которую Вы реализовали. Буду признателен.
Спасибо за Ваш ответ и участие, но мне в нём не хватило ... почти всего. Не лучшая идея - почему? Конкретно почему? Есть доказательства? Или не пробовал никто? Может и не лучшая, а вдруг лучшая? =) Первое решение "такого" плана - какого? Из фронта писал на backbone\marionette, view.js, angular1 немного, angular2 - много, react - немного, свой вело-фреймворк создавал дважды. (ключевое слово - вело). Ну а так, по мелочи - пожалуй почти на всех популярных решениях писал немного. Так что не знаю, вроде бы не первое решение такого плана, если речь о ajax и SPA.
Большое спасибо за развёрнутые ответы, это ценная информация.
(дальше целый абзац, который не по делу и его можно не читать)
Но для меня всё это будет, пожалуй, оверхед, т.к. у меня цель не только разобраться в DDD и LayerArchitect, но еще и практиковать кучу различных технологий от начиная с OS (bash, linux, администрирование, конфигурирование, виртуализация и provision), продолжая сервером бекенд, на котором Yii2 с уже переписанным каркасом под слои и инфраструктурой для удобного баг-фикса и вообще для удобного развёртывания и разработки проекта (в связке с MySQL и MongoDB, если успею), фронтендом с Angular2 и TypeScrypt, который я не использовал никогда, но написал уже некоторую часть приложения (кстати, интересно). В придачу к этому еще всякие не технические штуки типа продаж, руководства новосозданной командой, тайм-менеджмента, таск-менеджмента, ведения базы знаний, документации, распределения обязанностей. Казалось бы - максималистическая чушь, многие считают, что нужно заниматься одним и не лезть куда попало. Но я спецом уволился с последней должности, чтоб наладить вот такое вот хобби. Так что этот вопрос - это только часть моих увлечений.
Но всё таки касательно менее наполеоновских планов, чем Вы описали (я банально не успею разобраться с CQRS и ES, уже читал об этом, хотя это очень интересно). Можете прокомментировать мою задумку на приложение?
Само приложение - это автоматизация процесса оказания услуг. К нам обращается клиент, у него есть проект (зачастую это не идея - а существующий проект), он может создавать задачи по проекту, обсуждать с инженерами. Инженеры могут запрашивать некоторые шаблоны на заполнение - типа FTP, admin-panel, hosting-panel и т.д.
Мои "сотрудники" (бывшие "ученики") занимаются обслуживанием проектов на WordPress и мелким ремонтом\оптимизацией - то, что никто делать не хочет на рынке, ибо сильно "крутые".
На фронтенде пока не совсем понятно, что будет, т.к. у меня нет хорошего опыта Angular2 & TypeScript. Много вопросов, пока не могу определиться с зоной ответственности фронтенда, но я работаю над этим. Пока он просто работает по простому CRUD-REST, но я уже предусмотрел, что REST нужно будет сделать гибридным, чтобы передавать действия, иначе будет оверхедное злоупотребление идеи ресурсов. Кстати, конечно же SPA совсем тут не обязательно - это я уже для прокачки опыта усложнил, интересна технология TS.
Бекенд принимает REST запрос (иногда это может быть действие, к примеру "начать обсуждение проекта" - что в итоге меняет в объекте статус). Есть слой контроллеров и действий. Класс контроллера отвечает за авторизацию на действие, разрешает cors, перенаправляет на action. Класс action - это как бы сервис слоя Presentation. Он просто принимает запрос, передаёт данные в сервис приложения, максимум - делает очень простые проверки, ставит HTTP статус и возвращает данные, которые уже фреймворком преобразуются в JSON и уходят на клиент.
Сервис слоя приложения является моделью бизнес-процесса (?) и является самой толстой частью. Он может вызывать несколько действий (к примеру, создать объект, записать в логи), что позже будет переписано, например, в декораторы, но это позже. В простом случае, сервис может взаимодействовать либо напрямую с бизнес-объектом, либо запрашивать его через хранилище (репозиторий). Например, может создать бизнес-объект, записать в него данные, которые пришли с клиента, а потом через репозиторий и метод save сохранить его в базу.
Репозиторий как сервис уровня инфраструктуры. У меня он, пожалуй, не каноничный. Он является моделью хранилища. Умеет сохранить чистый бизнес-объект в базу (без ActiveRecord, только DAO и QueryBuilder), умеет по запросу типа fetch вернуть бизнес объект. Внутри имеет всякие вспомогательные конвертеры, которые позволяют воссоздать запрошенный бизнес-объект по данным из БД (вот сейчас понял, что не надо заново создавать, это ошибка. Нужно десериализовать по данным). Является адаптером между "чистыми" бизнес объектами и их способом хранения.
Ну и сам слой бизнес модели - сущности и объекты-значения, агрегаты. Пытаюсь сделать модели Rich, а не Anemic, но не уверен, что всё правильно понимаю. Anemic - это понятно. А Rich - если я правильно понимаю, это добавляет методы поведения. Т.е. объекты могут менять свои свойства, избавляя от этого слой приложения, который просто может вызвать метод, в зависимости от action. Но тут ен понятно, как распределить обязанности между моделями, чтоб не нарушать SRP. Какой объект чьи состояния может менять? Какие методы должны быть у модели? Не очевидно, хоть с логикой дружу немного.
Для меня шло в разрез логике, к примеру, что сущность "задание" может иметь метод "startConversation()", который меняет её статус и задание становится в состоянии "переговоры". Ведь вещи не могут менять своё состояние... Это делает объект, наделённый волей... И пошел-поехал загоняться в философию. У меня получилось, что никто, кроме наследников класса Human не может ничего менять. Позже я понял, что это пустая трата времени и надо немного иначе смотреть на модель. Остановился на том, что объект может менять своё состояние и состояние "подчинённых" объектов. Хотя масса вопросов (и подавленной агрессии) осталось. Если подбросите идею, как сделать красивую и логичную модель для перфекциониста в условиях умирающих запросов - буду признателен.
Конечно, появятся еще интерфейсы, но т.к. пока всё очень динамично, я подгоню интерфейсы, когда определюсь с деталями реализации, хоть надо и наоборот.
Как то так. Сейчас нет намерения пытаться прыгнуть в космос и сделать всё совсем идеально, но хочу сделать заготовку хорошей архитектуры с грамотно распределенными обязанностями/ответственностями. Золотую середину нащупать, чтоб без оверхедов, но и без transaction-script-ов и нарушения SOLID. Может я много хочу просто... =))
Я при попытках моделировать предметную область на PHP понял, что упираюсь в факт смерти потока. Как Вы считаете, как можно "жить с этим"? Ведь я не могу смоделировать что-то по настоящему похожее на предметную область, в рамках одного запроса я восстанавливаю из базы только кусок предметной области, с которым работаю.
У Вас в компании это, наверное, не правильно назвали, либо мы говорим не об одном и том же. data driven development - это способ разработки, ориентированной на данные. Так же, как есть ориентированная на события или на логику предметной области. DataDD - это (грубо говоря) когда вы проектируете хранилище данных, а поверх него потом генерируете модели записей таблиц, как позволяют легковесные фреймворки типа Yii, Laravel. Может, я чего то не знаю...
Про графики очень интересно, но какое же у вас множество измерений, что вы его отображаете на графиках и анализируете, а не смотрите в таблицах/списках? Я посмотрел Вашу компанию мельком и совершенно не могу представить, где у Вас применимо то, что вы описываете. Или Вы имеете ввиду, что можете отследить падение продаж и сделать вывод, что что-то не работает? А если это произошло не из-за поломке, а по другой тысяче возможных причин? Расскажите подробнее, если не сложно?
В моем приложении про подключение к бд знает компонент адаптера БД - надстройка над PDO, конфигурируется через ServiceLocator. Если Вы об этом, конечно. Но это часть фреймворка, я просто использую сконфигурированный компонент ORM на уровне инфраструктуры (в репозиториях, которые объединяют репозитории, как сервисы инфраструктурного слоя и коллекции по Эвансу - это моё компромиссное решение, позже разделю обязанности, возможно).
Про жизненный цикл не совсем понял. В php вообще с этим сложно. Технически, агрегат удаляется из памяти после каждого запроса, т.к. процесс убивается. А потом, со следующим запросом, я забираю данные из БД и собираю агрегат заново, десериализую его. Это сильно сбивает с толку. И сбивает с толку то, что я восстанавливаю только часть модели. К примеру, есть заказчик, есть проекты. Если я меняю его проект, я ведь не буду восстанавливать из базы всю коллекцию проектов, да и модель самого заказчика ресурсозатратно загружать. Получается как то странно. Может, лучше на сервере только REST сервер держать, а DDD на Angular2 на клиенте... Там ведь процесс в браузере дольше живёт и всё более "смоделированно" получится. Не знаю, понятно ли я объясняю суть.
HTTP не связан с взаимодействием с БД, как по мне, потому что сервис, на который попадает запрос, может запросить данные из файла, из не SQL хранилища или вообще с другого сервиса. У меня гибридный REST (гибридный, потому что у меня есть глаголы, а не только существительные, мне не понравилось помегательство на ресурсах, т.к. в итоге всё равно получается RPC через ресурсы).
Никто не должен диктовать организацию DDD ядра, кроме здравого смысла и логики. Ну, т.е. кроме самой предметной области, которая моделируется. Если в рабочих условиях - то здорово, когда есть доменный эксперт, который посодействует с тем, чтоб разобраться с предметами и связями. Но в моём случае я пишу своё приложение, которое автоматизирует работу аутсорс команды. Есть кастомер, у него проекты, у проектов задачи, у задач разработчики-исполнители и т.д. (Хотя, скорее не у задач разработчики, а у разработчиков задачи).
xfg: Большое спасибо. Я согласен, надо дело делать. Ответы мне помогли упорядочить имеющиеся знания и пересмотреть заблуждения, теперь возьмусь за практику. Да и от настройки виртуальной машины уже глаза выпадают и душа плачет, пора код писать =)
Спасибо. Скажите, а можно использовать ActiveRecord, но более мудро. Т.е. отделить модели предметной области в отдельные классы, а ActiveRecord оставить, как модель таблицы в базе данных? А чтоб какой-то маппер их связывал, заполнял AR из модели и сохранял. Плюс реализовать сервисный слой, который будет использоваться контроллерами, а внутри него будет связь взаимодействия AR и предметной области. Т.е. вопрос типа "как правильно использовать Yii2\Laravel", не в контексте RAD? Или не стоит так напрягаться и выдумывать? Просто использование Yii2, к примеру, мне бы сэкономило изучение доков нового фреймворка, а AR, хоть и анти-паттерн, всё же, наверное, можно его использовать с умом в хорошей архитектуре, я думаю.
Посоветуете статьи по проектированию доменной логики и многоуровневой архитектуры? Желательно, без привязки к фреймворку. Очень хочу прочитать книги по DDD, но судя по тому, как спорят читавшие их люди, они всё равно не определились, следовательно надо будет нырнуть в книги с головой и практикой, что перечеркнет прочтение моих текущих книг. Конечно, слабый аргумент, но пока хотелось бы практики. Уверен, что теорию можно объяснить в сжатом виде.
Спасибо. Правильно ли я понимаю, что не обязательно отказываться от ActiveRecord в Yii2, например, а хранить слой доменных объектов отдельно в самописных классах, используя AR, как модели ТАБЛИЦ, а предметную модель, как ... предметную модель? Смогу ли я в случае чего отказаться от AR в пользу другой ORM, или сразу... предсказать? И странный вопрос. У меня есть книга по Yii2 и там очень хорошо и аргументировано описана разработка приложения через тестирования с отделением предметной области (Марк Сафронов). Но там нет ничего о REST. Если я просто "проигнорирую" различные способы работы с формированием HTML на сервере, переложив это на client framework, и организовать таким образом по хорошим практикам из книги REST stateless, или у меня получится просто API с RPC?