Вы путаетесь немного. Вы говорите о вводе даты дня рождения и хотите описать его 3мя полями. 3 поля это только интерфейс для ввода одной, единой сущности — день рождения.
Правильней использовать календарь для выбора даты;
Если вам так хочется использовать 3 отдельных поля то вы должны свернуть их в единое целое в контроллере перед началом валидации. Обычно этим занимаются компоненты форм;
Валидировать вам всё равно нужно конечную дату в целом, а не её части и выводить вам нужно сообщение об ошибке для всей даты.
Пример:
2017-04-31 — в апреле 30 дней;
2017-02-29 — не високостный год;
123-13-44 — не валидная дата впринципе. Нет смысла выводить сообщения об ошибке для каждой части даты;
3000-01-01 — день рождения не может быть в будущем.
Ну почему же. Там не всегла все строго логично, люди не только короткий путь выбирают, дорожки бывают замысловатые. Что же это, если не UX?
Так я и не говорю что получившиеся дорожки логичны, хотя логика в них прослеживается. Я говорю что это UX по отношению к парку, а не к дорожкам. После того как UX парка сформировался, мы подстраиваем интерфейс (дорожки) под требования пользователей. Это совсем другая история.
Если мы сами проложим дорожки как мы считаем правильным, то люди будут ходить по ним, не смотря на то что им не удобно. Это и будет UX по отношению к дорожкам. Это именно то что получилось с ссылкой на логотипе. Пользователи подстроились под новые веяния дизайнеров, а того ли они хотели?
Как раз английские дорожки это скорее пример логичности, а не user experience. User experience говорит о том что пользователи подстраиваются под существующие реали, а не интерфейс подстраивается под требования пользователя.
Пользователи научились переходить на главную по логотипу потому что "умные" дизайнеры решили что ссылка "Гланая" пользователям не нужна.
Я не говорю что это плохо. Просто надо понимать от куда ноги ростут прежде чем продвигать эту идею.
DTO это про передачу данных. Я DTO рассматриваю как средство общения доменного слоя и слоя имплементации. Возможно я черезчур связываю DTO и слой реализации и в результате доменный слой оказывается зависимым от слоя реализации через DTO.
К сожалению, я не нашёл другого способа защетить доменный слой от использования его вне бизнесс процессов.
И, да, не считаю нужным вводить в модель кто и когда её создавал и модифицировал, если это делается только для административных целей
Согласен с вами. Об этом я и написал в статье. В данном случае лучше использовать лог-файл и вынести логирование за пределы сущности, например в обработчики доменных событий. Я привел это только как пример.
Но, как я уже говорил, логирование на уровне сущностей может быть нужно для голосований, если мы хотим ограничить количество голосов от одного пользователя. Если голосовать могут только авторизированные пользователи, то мы привязываем голос к пользователю по его ID, а если могу и анонимные, то нужно генерировать GUID на основе IP и User-Agent.
Еще дата создания сущности может быть нужна для применения миграций, когда нам нужно например, изменить что-то в записях которые были созданы после 2017-01-01. Можно конечно извлечь эту информацию из лога, но это очень трудоемко.
А вот еще один реальный бизнес-процесс: удалять из бд все записи старше 6 месяцев. Без знания даты создания сощности это сделать невозможно.
Также, дата и авторство изменения могут быть нужны в CRM, когда отслеживание таких действий является частью бизнес-процесса. В лог-файле никто копаться не будет.
Ну и на последок, приведу пример использование DTO на примере счетчика просмотров:
class Video
{
public function view(ViewRequest $request)
{
if ($request->getVideo() !== $this) {
throw new \InvalidArgumentException();
}
$this->total_views++;
return new View($request);
}
}
Метод принимает запрос на просмотр, применяет его и создает новую сущность которую мы уже и будем логировать, но за пределами этой сущности.
Эти навороты делаются для сохранения консистентности данных, то есть чтобы нельзя было в любом месте программы инкрементировать просмотр без реального просмотра.
Хорошо, пусть будет vagrant. У вас в виртуалке рабочая копия, снимок репозитория или хостинг?
У меня в vagrant все. База, исходники, репозиторий и тд. Это не точная копия прода, так-как отличаются некоторые параметры окружения, но в остальном копия, максимально приближена к прод.
Если говорить вашим языком:
Вы сами заявляете, что у вас есть кожух на циркулярке, но ваши люди продолжают резать руки. Значиь либо кожух плохой и не защищает, либо людей нужно учить им пользоваться.
У меня нет кожуха на циркулярке. Я и мои коллеги не режем руки. Может не в инструменте дело?
PS: не смотря на мои критические заявления, я не хочу сказать что git лучше hg. Вам он больше нравится и лучше подходит. Окей. Рад за вас. Я не хочу оспаривать ваш выбор. Я лишь хочу донести мысль, что hg не серебрянная пуля. Он не решает ваши проблемы в полной мере, как и не будет их решать git.
Мне это нужно, но я не могу настраивать хуки на машинах других разработчиков. Со своими коммитами я сам разберусь, но копаться мне нужно в чужих.
Есть такая штука, называется: Внутренний регламент разработки ПО.
Документ в котором описано что и как нужно писать, а что писать не надо, code style и т.д. В него также входит описание настройки окружения и работы с ним. Каждый разработчик обязан ознакомится с регламентом и подписать его. В документе можно описать установку хук для гита.
В другом комментарии вы упомянули контейнеры. На контейнерах можно собрать окружение для проекта и распространять между разработчиками именно его. Таким образом у всех разработчиков будет одинаковое и актуальное окружение. В те же контейнеры можно добавить хуки для гита.
Даже если другие разработчики работают на фрилансе удаленно, и вообще они индусы, то все равно можно распространить между ними регламент и контейнер с окружением.
Если вы находите ресурсы для контроля за работой других разработчиков, то найдите ресурсы для регламентирования и упорядочивания их работы.
Не усложняйте работу себе и другим.
решение о том попадёт ли фича в релиз может быть принято только после полного её тестирования и в том числе тестирования совместимости её с другими фичами релиза
Вы не заметили что описали рекурсию? Фича попадет в релиз только после проверки совместимости с другими фичами которые тоже должны пройти проверку на совместимость в том числе и с фичами которая добавляются в релиз после них.
Тестирование на совместимость в идеальном мире должно происходить многосторонне. В вашем примере получается, что группа разработчикав работавшая над фичей А должна проверить все ли у них работает после объединения с фичей Б, а разработчики фичи Б должны проверить весь свой функционал после мерджа с фичей А. Тестирование должно повторится после добавления фичи С и еще раз после добавления фичи Д и т.д.
Да, мы можем тестировать ветку на совместимость с другими ветками которые должны попасть в релиз. Но пока релиз не создан это просто висячие в воздухе ветки. Их список знает только тимлид и нет гарантии что пока вы тестируете ветки на совместимость не изменится список веток и сами ветки. На мой взгляд это перебор. Тестирование ради тестирования. Если фич всего 2-3, то еще можно жить, а если 30-40, то уже проблема тестировать все это у себя.
Потому я и говорю что нужна ветка с релизом чтоб не делать одну и туже работу многократно:
Мерджмастер создает ветку релиза (это может быть develop, release-678, issue-123 и тд. Название в данном случае не столь важно).
Мерджит туда все фичи и баги которые должны попасть в следующий релиз.
Если есть конфликты, то релиз отменяется и тикеты возвращаются разработчикам для доработки. Возвращаемся к п. 1
Если все смерджилось нормально, то ветка отправляется на тестирование на совместимость.
Каждая команда проверяет работу того куска за который отвечает она.
В случае проблем с совместимостью релиз отменяется и задачи возвращаются на доработку. Возвращаемся к п. 1
После успешного завершения тестирования релиз выкатывается.
Идея с feature-123.api-345.example.org моя голубая мечта и я пытался такое внедрить, но у меня еще не было ни одного проекта и компании которые могли себе такое позволить, а я работал над очень крупными hl проектами с милионами пользователей. Проблема же не только в доменах и автоматическом развертывании фич. Проблема еще в том что фичи зачастую завязаны на базе и для каждой фичи нужна своя копия базы, может и урезанная, но своя. Тоже может касаться NoSQL и ElasticSearch. Фактически, окружение для фичи должно быть максиму приближено к прод, но должно быть изолировано от других фич. А это уже совсем не детские ресурсы. Может в mail.ru или яндекс такое есть)))
PS: мне немножко странно почему вы релиз тестируете на проде и сливаете его в местер только после завершения тестирования. Мастер должен быть всегда эквевалентен проду. А для фиксации статуса используются теги, они же релизы в большинстве случаев. Если на проде баг то мы откатываем как прод, так и мастер. Не должно быть разделения. А то у вас получается мастер вообще как-то отдельно от всего, в воздухе висит. Ну это уже ваше дело. Я не критикую.
hg из коробки может добавлять номер тикета в коммит?
Именно номер тикета, а не название ветки?
И hg из коробки привязывает коммит к тикету?
Похожу вы просто не понимаете о чем говорите.
Да, git не добавляет название ветки из коробки, потому что это просто не нужно. А тем кому это нужно могут настроить хук.
Проблема то не в инструменте, а в умении им пользоваться.
Цель статьи — дать понимание, что мы используем Dependency Inversion, чтобы разделить модули асбтракцией, Dependency Injection, чтобы избавиться от инстантинации вручную, а реализуем это посредством фреймворка, построенного по принципу Inversion of Control. И ничто из этого не является синонимом друг друга.
Вот это стоило написать в статье, а то лично я понял всё только после вашего комментария.
И да, фраймворки, как правило, реализуют IoC по средствам Service Locator у себя в недрах.
Согласен. Хотя есть календари которые позволяют быстро пролистывать года.
Вы путаетесь немного. Вы говорите о вводе даты дня рождения и хотите описать его 3мя полями. 3 поля это только интерфейс для ввода одной, единой сущности — день рождения.
Пример:
2017-04-31— в апреле 30 дней;2017-02-29— не високостный год;123-13-44— не валидная дата впринципе. Нет смысла выводить сообщения об ошибке для каждой части даты;3000-01-01— день рождения не может быть в будущем.RegisterEnglishCardCommand и RegisterChinaCardCommand не?
Так я и не говорю что получившиеся дорожки логичны, хотя логика в них прослеживается. Я говорю что это UX по отношению к парку, а не к дорожкам. После того как UX парка сформировался, мы подстраиваем интерфейс (дорожки) под требования пользователей. Это совсем другая история.
Если мы сами проложим дорожки как мы считаем правильным, то люди будут ходить по ним, не смотря на то что им не удобно. Это и будет UX по отношению к дорожкам. Это именно то что получилось с ссылкой на логотипе. Пользователи подстроились под новые веяния дизайнеров, а того ли они хотели?
Как раз английские дорожки это скорее пример логичности, а не user experience. User experience говорит о том что пользователи подстраиваются под существующие реали, а не интерфейс подстраивается под требования пользователя.
Пользователи научились переходить на главную по логотипу потому что "умные" дизайнеры решили что ссылка "Гланая" пользователям не нужна.
Я не говорю что это плохо. Просто надо понимать от куда ноги ростут прежде чем продвигать эту идею.
Тут надо понимать что переход на главную по щелчку на логотип это user experience, а не логичное поведение. Это не одно и тоже.
DTO это про передачу данных. Я DTO рассматриваю как средство общения доменного слоя и слоя имплементации. Возможно я черезчур связываю DTO и слой реализации и в результате доменный слой оказывается зависимым от слоя реализации через DTO.
К сожалению, я не нашёл другого способа защетить доменный слой от использования его вне бизнесс процессов.
Еще один аргумент в пользу использования геттеров и сеттеров в DTO
Спасибо за замечание.
Поспешил я, RFC не приняли.
Я пока еще на 5.6 и путаюсь еще в нововведениях 7.x
Согласен с вами. Об этом я и написал в статье. В данном случае лучше использовать лог-файл и вынести логирование за пределы сущности, например в обработчики доменных событий. Я привел это только как пример.
Но, как я уже говорил, логирование на уровне сущностей может быть нужно для голосований, если мы хотим ограничить количество голосов от одного пользователя. Если голосовать могут только авторизированные пользователи, то мы привязываем голос к пользователю по его ID, а если могу и анонимные, то нужно генерировать GUID на основе IP и User-Agent.
Еще дата создания сущности может быть нужна для применения миграций, когда нам нужно например, изменить что-то в записях которые были созданы после 2017-01-01. Можно конечно извлечь эту информацию из лога, но это очень трудоемко.
А вот еще один реальный бизнес-процесс: удалять из бд все записи старше 6 месяцев. Без знания даты создания сощности это сделать невозможно.
Также, дата и авторство изменения могут быть нужны в CRM, когда отслеживание таких действий является частью бизнес-процесса. В лог-файле никто копаться не будет.
Ну и на последок, приведу пример использование DTO на примере счетчика просмотров:
Метод принимает запрос на просмотр, применяет его и создает новую сущность которую мы уже и будем логировать, но за пределами этой сущности.
Эти навороты делаются для сохранения консистентности данных, то есть чтобы нельзя было в любом месте программы инкрементировать просмотр без реального просмотра.
Мой комментарий получился немного великоват и я оформил его в виде отдельной статьи:
https://habrahabr.ru/post/321892/
У меня в vagrant все. База, исходники, репозиторий и тд. Это не точная копия прода, так-как отличаются некоторые параметры окружения, но в остальном копия, максимально приближена к прод.
Если говорить вашим языком:
Вы сами заявляете, что у вас есть кожух на циркулярке, но ваши люди продолжают резать руки. Значиь либо кожух плохой и не защищает, либо людей нужно учить им пользоваться.
У меня нет кожуха на циркулярке. Я и мои коллеги не режем руки. Может не в инструменте дело?
PS: не смотря на мои критические заявления, я не хочу сказать что git лучше hg. Вам он больше нравится и лучше подходит. Окей. Рад за вас. Я не хочу оспаривать ваш выбор. Я лишь хочу донести мысль, что hg не серебрянная пуля. Он не решает ваши проблемы в полной мере, как и не будет их решать git.
Я с контейнерами не работал. Если верить статьям по работе, то это можно сделать. Я же имел дело с использованием такого подхода в vagrant.
Да, фактически я скопиравал, переупорядочил и переформулировал ваш список, так же как и вы мой до этого)))
Есть такая штука, называется: Внутренний регламент разработки ПО.
Документ в котором описано что и как нужно писать, а что писать не надо, code style и т.д. В него также входит описание настройки окружения и работы с ним. Каждый разработчик обязан ознакомится с регламентом и подписать его. В документе можно описать установку хук для гита.
В другом комментарии вы упомянули контейнеры. На контейнерах можно собрать окружение для проекта и распространять между разработчиками именно его. Таким образом у всех разработчиков будет одинаковое и актуальное окружение. В те же контейнеры можно добавить хуки для гита.
Даже если другие разработчики работают на фрилансе удаленно, и вообще они индусы, то все равно можно распространить между ними регламент и контейнер с окружением.
Если вы находите ресурсы для контроля за работой других разработчиков, то найдите ресурсы для регламентирования и упорядочивания их работы.
Не усложняйте работу себе и другим.
Перечитал еще раз ваш комментарий
Вы не заметили что описали рекурсию? Фича попадет в релиз только после проверки совместимости с другими фичами которые тоже должны пройти проверку на совместимость в том числе и с фичами которая добавляются в релиз после них.
Тестирование на совместимость в идеальном мире должно происходить многосторонне. В вашем примере получается, что группа разработчикав работавшая над фичей А должна проверить все ли у них работает после объединения с фичей Б, а разработчики фичи Б должны проверить весь свой функционал после мерджа с фичей А. Тестирование должно повторится после добавления фичи С и еще раз после добавления фичи Д и т.д.
Да, мы можем тестировать ветку на совместимость с другими ветками которые должны попасть в релиз. Но пока релиз не создан это просто висячие в воздухе ветки. Их список знает только тимлид и нет гарантии что пока вы тестируете ветки на совместимость не изменится список веток и сами ветки. На мой взгляд это перебор. Тестирование ради тестирования. Если фич всего 2-3, то еще можно жить, а если 30-40, то уже проблема тестировать все это у себя.
Потому я и говорю что нужна ветка с релизом чтоб не делать одну и туже работу многократно:
Идея с feature-123.api-345.example.org моя голубая мечта и я пытался такое внедрить, но у меня еще не было ни одного проекта и компании которые могли себе такое позволить, а я работал над очень крупными hl проектами с милионами пользователей. Проблема же не только в доменах и автоматическом развертывании фич. Проблема еще в том что фичи зачастую завязаны на базе и для каждой фичи нужна своя копия базы, может и урезанная, но своя. Тоже может касаться NoSQL и ElasticSearch. Фактически, окружение для фичи должно быть максиму приближено к прод, но должно быть изолировано от других фич. А это уже совсем не детские ресурсы. Может в mail.ru или яндекс такое есть)))
PS: мне немножко странно почему вы релиз тестируете на проде и сливаете его в местер только после завершения тестирования. Мастер должен быть всегда эквевалентен проду. А для фиксации статуса используются теги, они же релизы в большинстве случаев. Если на проде баг то мы откатываем как прод, так и мастер. Не должно быть разделения. А то у вас получается мастер вообще как-то отдельно от всего, в воздухе висит. Ну это уже ваше дело. Я не критикую.
hg из коробки может добавлять номер тикета в коммит?
Именно номер тикета, а не название ветки?
И hg из коробки привязывает коммит к тикету?
Похожу вы просто не понимаете о чем говорите.
Да, git не добавляет название ветки из коробки, потому что это просто не нужно. А тем кому это нужно могут настроить хук.
Проблема то не в инструменте, а в умении им пользоваться.
Ну это уже савсем идеальный мир. Я с таким не сталкивался и необходимости в такой идеалезированности не было.
Но я учту вашу мысль на будущее
Вот это стоило написать в статье, а то лично я понял всё только после вашего комментария.
И да, фраймворки, как правило, реализуют IoC по средствам Service Locator у себя в недрах.