Комментарии

Если вам требуется поменять на мобильном именно верстку, то есть HTML-разметку, то вы можете поместить ее в отдельный блок, например для хедера (аналогично — для прочих крупных блоков, которые будут отличатьтся от десктопной версии). Этот блок будет скрываться на больших разрешениях через свойство display: none, и показываться на мобильных через display: block. Соответственно, блок с десктопной версией также придется обернуть в обертку, скрывать его на мобильных и показывать на десктопе.

@media  screen and (min-width: 525px) {
  .header-pc {
    display: block
  }
  .header-mobile {
    display: none
  }
}

@media  screen and (max-width: 525px) {
  .header-pc {
    display: none
  }
  .header-mobile {
    display: block
  }
}

<div class="header-pc">Header On PC</div>
<div class="header-mobile">Header on Mobile</div>

Однако это достаточно «костыльное» и некрасивое решение. Правильнее было бы изначально построить разметку страницы так, чтобы в зависимости от разрешения часть блоков можно было скрыть, а часть — расположить на странице иначе. В этом смысл адаптива и его отличие от респонсива: адаптивная страница перестраивает свою структуру средствами CSS в зависимости от разрешения экрана, то есть это именно, как вы говорите, кардинально различающиеся страницы визуально, хотя их разметка остается неизменной на всех разрешениях.

CSS для мобильных назначаетcя через медиазапросы либо с использованием css-фреймворков вроде Bootstrap.

Мне нужно создать мобильную версию сайта, которая кардинально отличается от компьютерной по верстке и css. Это не просто адаптивный шаблон. Вопрос в том, как это сделать?

Теоретически, адаптивный веб-дизайн является лучшим решением. Но на практике большинство таких сайтов реализованы неправильно и приводят к увеличению времени загрузки.
Мои тесты показывают, что лучшее время загрузки — у мобильных сайтов, но есть значительные недостатки в такой реализации задачи.

По моему мнению, лучше всего использовать комбинацию из адаптивного веб-дизайна и RESS. В этом случае мы получаем все плюсы “резиновой верстки” и решаем две больших проблемы: использования множества файлов и медленную загрузку.

Первый эффект от программы — ничего не теряется, все задачи всех подразделений видны и постепенно исполняются. Наше большое колесо задач наконец стало продвигаться вперед, а не буксовать на месте. Даже самые забытые задачи, которые обычно спускались на тормозах, стали исполняться, и сегодня уже не понимаешь, как работали раньше

Перед DST CRM мы последовательно перепробовали несколько аналогичных продуктов, и каждый из них вызывал отторжение по разным причинам: либо на функциональном, либо на человеческом уровне. Поэтому переход на DST CRM вызвал настоящий вау-эффект: все понятно, все удобно, приятный интерфейс — сел и работай

Мы пользуемся ДСТ CRM восемь месяцев, и сейчас нам сложно представить, как мы обходились без него. Если говорить о конкретных результатах, то мы наблюдаем рост лояльности клиентов и повышение эффективности работы всего коллектива. ДСТ CRM создал особую рабочую атмосферу в нашей организации, в которую вовлечены и штатные, и удаленные сотрудники

В DST CRM статусы текущих дел отслеживаются в один клик. При этом оценка загруженности сотрудников позволила оптимально планировать работу. DST CRM, прежде всего, необходим компаниям, где координация деятельности сотрудников и отделов затруднена сложной структурой управления

На жизни разработчиков сказываются те бенефиты, которые они получают по месту работы. Все методики разработки направлены на улучшение бизнеса. DDD — это следующий этап после приближения разработки к собственно продукту. То есть нужно сначала разобраться, зачем разработчику знать то, над чем он работает.

Именно. Программист, осознанно работающий по DDD, должен обладать навыками аналитика. Хотя бы чтобы заметить, что новые желания плохо согласуются с имеющимися моделями и их надо изменять, а не тупо добавить пару свойств и с десяток if'ов.

С другой стороны, бизнес-аналитик может быть единственным экспертом предметной области, доступный программистам, и это тоже будет DDD. Детали реализации, как говорится.

Да, в подходе DDD считается, что чем меньше «переводов» и чем лучше разработчик сам понимает зачем он пилит ту или иную фичу, тем качественнее продукт на выходе.

В моей трактовке любая передача информации от человека человеку сопряжена с потерями. Если можно обойтись без — лучше обойтись.

Но сам по себе DDD не исключает архитекторов и аналитиков (как и дизайнеров с тестировщиками). Но не снимает с разработчика почетной обязанности погружаться в домен и бизнес.

Я исхожу из того, что код домена, написанный по DDD должен быть в целом понятен бизнесу (англоговорящему). И где-то в коде new Customer($name, $address) будет более понятно при таком подходе, чем CustomerFactory::create($name, $address). Хотя в принципе непринципиально. Можно и фабричным методом/классом, особенно в форме Customer::registerNewCustomer(($name, $address). Но вот программные зависимости, а не значения свойств сущности в конструкторе класса сущности, по-моему, зло, которого не должно быть независимо от того Doctrine это или нет. Для меня это говорит о плохой проработке модели, или о выборе непоходящего для DDD инструментария, типа использования в качестве сущности наследника какого-нибудь ACtiveRecord

Я уже где-то встречал это мнение, кажется в сообществе Doctrine так считается. Я думаю, это неправильный подход. Конструктор это по своей природе функция, которая вызывается при создании объекта в оперативной памяти некоторого процесса, для инициализации занимаемой им оперативной памяти. Это инфраструктурная вещь. Если у нас есть более высокоуровневая абстракция, если у нас одна и та же сущность может появляться в разных процессах, значит и для конструктора нужно создать более высокоуровневую абстракцию, специальный бизнес-конструктор, который и будет вызываться один раз. А не пытаться через рефлексию и аннотации имитировать то, что должно быть в конструкторе.

Инжектить сервис в сущность крайний способ организации их взаимодействия для меня в принципе, а double dispatch — единственный приемлемый способ сделать это. Почти автоматически заношу его в техдолг.

То есть инжектить сторонние зависимости через сигнатуру метода сущности? Тогда остаётся вопрос, в какой момент остановиться и не отработать весь процесс приложения в этом методе сущности)

Точно не помню, есть ли дословно, но слой доменной логики, где и лежат сущности не должен зависеть от других слоёв, что исключает зависимость от инфраструктурных и т. п. сервисов. То есть инжектить какой-нибудь инфраструктурный эмиттер событий нельзя, потому что это будет зависимостью от инфраструктурного слоя.

Остаются бизнес-сервисы, сервисы предметной области. Тут подход другой: мы моделируем сущность, она имеет жизненный цикл и создаётся, конструируется только один раз. То есть ее конструктор должен вызываться только один раз. Если про rest-like веб API говорить, то где-то в обработчике соответствующего POST метода. Если про UI, то где-то в обработчик кнопок new/create/etc.

Используемый ORM/ODM/… или даже язык в целом, может не допускать такой сценарий и придётся использовать какой-то именованный конструктор/фабричный метод/фабрику, но вот семантика должна сохраниться, то есть инжектить сервисы через конструктор даже под их капотом всё равно нельзя, по-моему. У класса сущности должна быть одна ответственность — моделировать сущность предметной области. Если и надо что-то инжектить в сущность, то из-за эфемерной природы программных сервисов (их в базу не сохранишь), то через double dispatch

Вот это мне не удаётся хорошо обосновать. Стараюсь через Clean Architecture, но с сомнительным успехом. Еще через глобальное состояние и «чистоту» эффектов, но через это по-видимому я вообще только себе могу что-то доказать. В материалах по DDD разве есть что-то про это? По-моему нет.

Во-первых, DDD не ограничивает источники единого языка, он просто должен быть единым в рамках чётко определённого контекста. И бизнес вполне может перестать использовать некоторые «доморощенные» термины в пользу предложенных разработчиками. И это реально работает.

DDD роли бизнес-аналитика и архитектора не исключает. Более того, субъективно, их функции становятся более важными. Бизнес-аналитик же по определению должен быть экспертом предметной области. Или нет? Да и архитектуру кто-то должен определять. Например, «достоин» ли какой-то контекст, агрегат или даже сущность выноса в отдельный сервис или нет.

В пределе, наверное, бизнес-аналитик и архитектор могут «заставить» разработку идти по DDD даже без ведома разработчиков. Архитектор определит слои, бизнес-аналитик контексты и модели, а разработчики будут это имплементировать. Разве что жаловаться будут на то, что эти самодуры лезут в детали реализации, типа какая разница как у нас класс называется, если пользователь этого не знает. Или что запрещают инжектить сервис в сущность через конструктор, хотя это удобно.

Да, есть такое. Поэтому мы и пытались сделать лаг репликации минимальным.

Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.

Создает, но меньшую. Намного меньшую.