Снимается, но по претензии через поддержку вернуть можно. Раньше по крайней мере без проблем возвращал в таких ситуациях. Ну, и я не отменяю, если водитель просит. Пусть висит пока он где-то катается, я просто второй заказ делаю. Потом так же пишу в поддержку, что он не приехал, деньги возвращают. К водителям штрафные санкции за отказы применяются, поэтому они сами и не сбрасывают заказы, а просят клиента отменить.
Например, для добавления приложения в «избранное» достаточно нажать на «+» и сделать выбор, после чего его можно легко переместить в нужное место.
Да, добавить действительно легко, а как удалить? И с перемещениями я так и не понял, кстати, в меню нашел, где их таскать можно, но это никак не влияет на их расположение на главном экране.
А как у ClickHouse с offset() и count()? Обычно это тяжелые операции для больших объемов, при этом весьма востребованные для просмотра статистических данных.
interface ClientBuilder
{
public function buildClient(): Client;
public function setId(ClientIdentity $id): ClientBuilder;
public function setCorporateForm($corporateForm): ClientBuilder;
public function setName($name): ClientBuilder;
public function setGeneralManager(Manager $generalManager): ClientBuilder;
public function setAddress(Address $address): ClientBuilder;
}
У Sufir «команды» это DTO для передачи данных между прикладным слоем и UI слоем (например HTTP). На этом слое у него, как я понимаю, реализация юзкейсов. Высокоуровневая логика, задающая последовательность действий и дергающая элементы слоя предметной области.
Совершенно верно.
У меня к примеру «билдеры» для всяких сущностей действуют как DTO. То есть я их объявляю в слое предметной области и использую преимущественно в прикладном слое. И все что они делают — это декларируют наполнение данными таким образом, что бы я чего не забыл сделать.
Ну, приблизительно так и я сделал в описанном случае. В домене объявлены интерфейсы билдеров, а реализация — это конечно уже инфраструктура, вызываются они у меня только в прикладном (пока больше нигде не понадобились). Попробовал в качестве эксперимента, получилось неплохо.
> DTO это про передачу данных.
Да, я и говорю — «команды», сообщения CQRS (Запросы, Команды, События) и есть обычные DTOшки. Я применял Гексагональную архитектуру (порты и адаптеры) + CQRS. Очень эффективно и изящно получается, всё буквально само по местам становится. Рекомендую, изучите вопрос и опробовать. До этого я всячески пытался разделять слои, какие-то модули выделять, всё равно всё смазывалось.
Интересно и по теме, хотя и не совсем непосредственно ответ. Команды (DTO) и их обработчики я отношу к прикладному слою, а не к домену, и скармливаю их командной шине. Статья не о том в целом, вы скорее развиваете вопрос. Любопытно, спасибо за ответ и за DDD!
Конечно лучше, но в данной статье я ничего о DTO и их применении не говорил, тут речь только о сущностных. В модели предметной области DTO могут использоваться для реализации событий предметной области, в остальных ситуациях DTO не место в слое модели.
Нет, это конечно же не DTO и я начинаю с того, что бы как раз сделать шаг от анемичной модели к rich и превратить DTO в Entity. Но да, мы уже обсудили это в другом месте, моя ошибка. Для упрощения примера и акцента на теме создания объектов не стал упоминать о поведении, но из-за этого пример выглядит неубедительно. Хотя бы вкратце это оговорить нужно было.
Нет, этот метод явным образом в коде описывает бизнес-требования, к валидации он никакого отношения не имеет. Есть требование сформулированное бизнесом «нельзя оформить заказ на клиента без менеджера» (вот просто нельзя никогда, бизнесу не интересно как ты технически это реализуешь, ему важно что бы правило выполнялось) и оно в представленном коде легко прочитывается.
Никаких технических isValid() в модели быть не должно, их нет в едином языке и они не выражают никаких бизнес-правил. Сюда же и сеттеры, которые не несут никакой смысловой нагрузки с точки зрения предметной области.
В предметной области есть Клиент и Заказ, заказ может быть «Оформлен», Клиент может быть «Переименован» и т.д., поведение явно отражает бизнес-логику и единый язык. В этом основной смысл проектирования по модели — предметно-ориентированного проектирования. Ни о каких setSomething() и isValid() бизнес не знает и в проектируемой модели их быть не должно (иногда, конечно, технические ограничения требуют введения служебных методов в классы модели).
На уровне модели предметной области — выполнение ограничений предметной области (domain model). Валидация введенных пользователем данных — это задачи слоя отображения (presentation layer) и прикладного слой (application layer).
Вы предпочитаете так, ваше дело, я предпочитаю не смешивать слои, а разделяю ответственности в соответствии с SRP. Ваша валидация и красивости отображения ошибок к домену ни каким боком не относятся.
Я не «догмат» и даже не догматик, просто вы пишите вещи напрямую не связанные с узким вопросом рассмотренным в статье, все эти вопросы значительно шире.
А спецификация именно об этом (Э. Эванс «Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем», ИД «Вильямс» — 2011 г., стр. 205) или я не понял о чём вы вообще.
И почему выполнение бизнес-требований должно ограничиваться «валидацией до первой ошибки»?
А какая разница какое там количество ошибок? Первая — это уже не выполнение требуемых инвариантов.
Против альтернативных вариантов я тоже ничего против не имею. Более того, я думаю, что описанный мной построение объекта-сущности никак ей не противоречит. Напишите хорошую статью о контекстной валидации, это будет очень интересно.
Почему все так любят кидаться исключениями при валидации сущности?
Потому что вы смешиваете клиентскую валидацию и выполнение бизнес-требований. Бизнес-требования должны соблюдаться всегда и такой код вам не позволит их нарушить. Я вам дал уже пару ссылок по теме, это не относится к рассматриваемой теме.
В более сложных ситуациях можно применить спецификацию, о ней тоже есть у Эванса, Фаулера и Вернона.
В начале статьи указано:
Для понимания материала понадобится базовое представление о предметно-ориентированном проектировании.
В конце статьи список материалов по теме, начните оттуда. Если же вы знакомы с DDD, но просто не хотите применять данный подход — то какой смысл писать в данной теме, всё описанное имеет смысл только в рамкам проектирования по модели.
Снимается, но по претензии через поддержку вернуть можно. Раньше по крайней мере без проблем возвращал в таких ситуациях.
Ну, и я не отменяю, если водитель просит. Пусть висит пока он где-то катается, я просто второй заказ делаю. Потом так же пишу в поддержку, что он не приехал, деньги возвращают.
К водителям штрафные санкции за отказы применяются, поэтому они сами и не сбрасывают заказы, а просят клиента отменить.
Сдаётся мне, что во второй части вашего вопроса содержится ответ на его первую часть.
Это не первый ли случай в истории? )
У вас опечатка. Спасибо за дайджест!
А вы о чём?
Ну, приблизительно так и я сделал в описанном случае. В домене объявлены интерфейсы билдеров, а реализация — это конечно уже инфраструктура, вызываются они у меня только в прикладном (пока больше нигде не понадобились). Попробовал в качестве эксперимента, получилось неплохо.
Да, я и говорю — «команды», сообщения CQRS (Запросы, Команды, События) и есть обычные DTOшки. Я применял Гексагональную архитектуру (порты и адаптеры) + CQRS. Очень эффективно и изящно получается, всё буквально само по местам становится. Рекомендую, изучите вопрос и опробовать. До этого я всячески пытался разделять слои, какие-то модули выделять, всё равно всё смазывалось.
Тут на Хабре тоже есть несколько неплохих статей и в сети, ну и у Э. Эванса не в деталях но достаточно описано. Вот, что под рукой есть:
https://msdn.microsoft.com/ru-ru/magazine/mt238399.aspx
https://msdn.microsoft.com/magazine/mt147237
https://habrahabr.ru/post/314536/
Deleted. Пардоньте промахнулся.Никаких технических isValid() в модели быть не должно, их нет в едином языке и они не выражают никаких бизнес-правил. Сюда же и сеттеры, которые не несут никакой смысловой нагрузки с точки зрения предметной области.
В предметной области есть Клиент и Заказ, заказ может быть «Оформлен», Клиент может быть «Переименован» и т.д., поведение явно отражает бизнес-логику и единый язык. В этом основной смысл проектирования по модели — предметно-ориентированного проектирования. Ни о каких setSomething() и isValid() бизнес не знает и в проектируемой модели их быть не должно (иногда, конечно, технические ограничения требуют введения служебных методов в классы модели).
Вы предпочитаете так, ваше дело, я предпочитаю не смешивать слои, а разделяю ответственности в соответствии с SRP. Ваша валидация и красивости отображения ошибок к домену ни каким боком не относятся.
Именно так, это она и есть.
А спецификация именно об этом (Э. Эванс «Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем», ИД «Вильямс» — 2011 г., стр. 205) или я не понял о чём вы вообще.
А какая разница какое там количество ошибок? Первая — это уже не выполнение требуемых инвариантов.
Против альтернативных вариантов я тоже ничего против не имею. Более того, я думаю, что описанный мной построение объекта-сущности никак ей не противоречит. Напишите хорошую статью о контекстной валидации, это будет очень интересно.
Потому что вы смешиваете клиентскую валидацию и выполнение бизнес-требований. Бизнес-требования должны соблюдаться всегда и такой код вам не позволит их нарушить. Я вам дал уже пару ссылок по теме, это не относится к рассматриваемой теме.
В более сложных ситуациях можно применить спецификацию, о ней тоже есть у Эванса, Фаулера и Вернона.
В начале статьи указано:
В конце статьи список материалов по теме, начните оттуда. Если же вы знакомы с DDD, но просто не хотите применять данный подход — то какой смысл писать в данной теме, всё описанное имеет смысл только в рамкам проектирования по модели.