DTO тогда должен быть в общей DLL и домен будет от нее зависеть (чего я не вижу на картинке чистой архитектуры), либо DTO должны храниться в DLL домена, чего я тоже не припоминаю. Вы где храните DTO?
Класс, отражающий какой-то объект предметной области, внутри содержит бизнес логику, поля закрыты от изменения. И есть всякие публичные методы, которые позволяют что-то сделать с этой сущностью правильным способом.
Вы в своем комментарии упомянули Канаду и США, вот я про них и написал.
Если переходить к более обширному списку стран и благополучию в них - то для начала надо определиться с понятием благополучия (оно может быть разным у людей) и может стоит оценивать не только текущее состояние, но и то какие решения принимаются и результат?
И как я уже сказал - нет идеальных стран для всех, везде есть плюсы и минусы для конкретного человека.
Так, то есть вы используете DDD сущность + TableModule? Через первую вы запускаете сложные процессы домена, а через вторую - сохраняете в БД, если просто отредактировали на UI?
Конкретно в моем случае - это автоматическая обработка уже созданных заказов - они скачиваются и запускается обработка, но там есть процессы на обновление, отмену и редактирование через UI на всякий критический (редкий) случай (статус там менять нельзя просто так - только нажать кнопку и запустить процесс). Поля есть - заголовок (адрес, дата, номер) и линии заказа (это отдельная сущность со своими полями), вместе они aggregate root.
тут можно 1 функцией и 1 sql запросом обойтись
В целом, я это понимаю, но не понимаю как это подружить с DDD. На логическом уровне мне получается надо две сущности - одна DDD (чтобы пнуть емкий процесс после изменения статуса, там поля только на чтение, закрытые от изменений) и одна анемичная (active record, все что угодно, чтобы просто поля обновить). Да даже, чтобы просто создать сущность из CreateDTO - надо конструктор у сущности с 100500 полями (мне не нравятся такие конструкторы - в некоторых компаниях, например, code style, говорит что максимум 5 зависимостей / параметров в конструкторе или методе).
Дальше я начинаю думать, что во-первых - как это я так сделал две сущности, одна может сломать инварианты другой. Во-вторых - даже если согласиться, что это ок - уже слишком много классов. Это ж поля надо в два места добавлять, если новая фича появиться (DRY).
Появляются мысли - как это уложить в одной DDD сущности и наталкиваюсь на проблему, с которой и начал. В голове крутятся несколько вариантов, но они все выглядят костыльно.
Допустим, а как тогда делать форму редактирования некой сущности? Заказ например? Там 80% обновлений полей и 20% - это пнуть заказ дальше по процессу (триггер на изменение статуса).
Подскажите такую вещь - вот я сделал сущность, у нее свойства приватные (чтобы не нарушать ее состояние), и можно либо через конструктор значения передать, либо на каждое свойство реализовать метод UpdateXXX(value).
Далее у нас есть контроллер, там DTO, допустим там UpdateDTO и все те же поля для простоты. Как это все подружить на ООП языке, не добавляя 100500 параметров в конструктор или методов UpdateXXX?
Я так понимаю зависит от того, когда приехали. Сейчас очень нехорошее время - все сильно подорожало. То есть те же понаехи из прошлого на свои зарплаты уже не купят свои же дома сегодня (ну или это будет напряжней).
Все относительно, и везде можно найти плюсы и минусы.
В Канаде запрещено оружие, поэтому полиция менее нервная, чем в США. Тут человеческая метрическая система мер, а не эти локти и ноги. Но конечно список услуг и товаров меньше, по сравнению с США, где население в 8 раз больше.
Таких новостей не было, на фоне того, что Альберта грозится провести референдум, чтобы стать 51 штатом. В прошлом Квебек два раза пытался, один раз прям на грани. Но вроде никто у них налоги не отнимал.
А да, и они налоги снижают, правда символически, но факт - федералы снизили на 1% для первого налогового диапазона (57 - 115 что ли в год). И вроде как Альберта тоже собирается снизить налог провинции.
Да, я считаю, что широкое распространение персональных компьютеров, интернета, мобильных телефонов, а теперь и движение в сторону ИИ - является своего рода техническим прогрессом. И интересно узнать ощущения людей в том возрасте, на чьих глазах все это происходило. И как происходила адаптация.
Когда я вступил в сознательный и самостоятельный этап своей жизни (вуз) - почти все это уже было. На моем веку пока что - только появление чат гпт было революционным скачком.
UPD: я вполне осознаю, что чат гпт - это не ИИ, а «предсказатель следующего символа». Но это ощутимый сдвиг. Со временем, думаю человечество осилит AGI, и возможно даже я это увижу собственными глазами.
Так не только богатые делают - даже self employer может вычитать из налоговой базы кучу всего. Этим пользуются и уменьшают тем самым налог. Вот и получается - яхта машина на фирму.
Ну если грубо - зп 100 тр, на руки 87 (-13% ндфл), в ПФР и медстраховка еще 30% от 100 (там тоже есть ограничения в год и есть льготные категории компаний, в том числе ИТ)
Итого 130 ФОТ превращаются в 87 на руки, то есть на налоги уходит 43 тр - это еще ~0,5 зарплаты, если смотреть со стороны работника.
Что мещает относить?
Такой декларации не существует. Есть декларация 3-НДФЛ - это за крупные продажи (машина, квартира, не всегда ее надо подавать) и доход из зарубежных источников.
Таки в том-то и посыл - чтобы работник в России видел весь или почти весь ФОТ (там как раз выходит примерно 40-50%) в платежках, так же как и работник в Канаде, и сам бы относил декларацию каждый год в налоговую.
Ну в айтишных кругах ходит прикол - чтобы получить реальное время выполнения задачи, надо первичную оценку, данную условным программистом, умножить на число пи (~3.14) и число е (~2.7). Так как оба числа являются иррациональными (так же как порой и сами задачи в стиле "Реализовать статусную модель") и отражают фундаментальные математические вещи, что позволяет увязать это с математикой и получить реальное число в часах/днях/месяцах.
Понял, если неймспейсы физически не разделяются - тогда проще.
DTO тогда должен быть в общей DLL и домен будет от нее зависеть (чего я не вижу на картинке чистой архитектуры), либо DTO должны храниться в DLL домена, чего я тоже не припоминаю. Вы где храните DTO?
Класс, отражающий какой-то объект предметной области, внутри содержит бизнес логику, поля закрыты от изменения. И есть всякие публичные методы, которые позволяют что-то сделать с этой сущностью правильным способом.
Вы в своем комментарии упомянули Канаду и США, вот я про них и написал.
Если переходить к более обширному списку стран и благополучию в них - то для начала надо определиться с понятием благополучия (оно может быть разным у людей) и может стоит оценивать не только текущее состояние, но и то какие решения принимаются и результат?
И как я уже сказал - нет идеальных стран для всех, везде есть плюсы и минусы для конкретного человека.
Так, то есть вы используете DDD сущность + TableModule? Через первую вы запускаете сложные процессы домена, а через вторую - сохраняете в БД, если просто отредактировали на UI?
Конкретно в моем случае - это автоматическая обработка уже созданных заказов - они скачиваются и запускается обработка, но там есть процессы на обновление, отмену и редактирование через UI на всякий критический (редкий) случай (статус там менять нельзя просто так - только нажать кнопку и запустить процесс). Поля есть - заголовок (адрес, дата, номер) и линии заказа (это отдельная сущность со своими полями), вместе они aggregate root.
В целом, я это понимаю, но не понимаю как это подружить с DDD. На логическом уровне мне получается надо две сущности - одна DDD (чтобы пнуть емкий процесс после изменения статуса, там поля только на чтение, закрытые от изменений) и одна анемичная (active record, все что угодно, чтобы просто поля обновить). Да даже, чтобы просто создать сущность из CreateDTO - надо конструктор у сущности с 100500 полями (мне не нравятся такие конструкторы - в некоторых компаниях, например, code style, говорит что максимум 5 зависимостей / параметров в конструкторе или методе).
Дальше я начинаю думать, что во-первых - как это я так сделал две сущности, одна может сломать инварианты другой. Во-вторых - даже если согласиться, что это ок - уже слишком много классов. Это ж поля надо в два места добавлять, если новая фича появиться (DRY).
Появляются мысли - как это уложить в одной DDD сущности и наталкиваюсь на проблему, с которой и начал. В голове крутятся несколько вариантов, но они все выглядят костыльно.
И стало интересно как в реальности это решается.
Допустим, а как тогда делать форму редактирования некой сущности? Заказ например? Там 80% обновлений полей и 20% - это пнуть заказ дальше по процессу (триггер на изменение статуса).
Воды?
/s
Подскажите такую вещь - вот я сделал сущность, у нее свойства приватные (чтобы не нарушать ее состояние), и можно либо через конструктор значения передать, либо на каждое свойство реализовать метод UpdateXXX(value).
Далее у нас есть контроллер, там DTO, допустим там UpdateDTO и все те же поля для простоты. Как это все подружить на ООП языке, не добавляя 100500 параметров в конструктор или методов UpdateXXX?
😅😅😅
Но кстати в России тоже используются чашки и ложки, как единица измерения)
Я так понимаю зависит от того, когда приехали. Сейчас очень нехорошее время - все сильно подорожало. То есть те же понаехи из прошлого на свои зарплаты уже не купят свои же дома сегодня (ну или это будет напряжней).
Все относительно, и везде можно найти плюсы и минусы.
В Канаде запрещено оружие, поэтому полиция менее нервная, чем в США. Тут человеческая метрическая система мер, а не эти локти и ноги. Но конечно список услуг и товаров меньше, по сравнению с США, где население в 8 раз больше.
Таких новостей не было, на фоне того, что Альберта грозится провести референдум, чтобы стать 51 штатом. В прошлом Квебек два раза пытался, один раз прям на грани. Но вроде никто у них налоги не отнимал.
А да, и они налоги снижают, правда символически, но факт - федералы снизили на 1% для первого налогового диапазона (57 - 115 что ли в год). И вроде как Альберта тоже собирается снизить налог провинции.
Да, я считаю, что широкое распространение персональных компьютеров, интернета, мобильных телефонов, а теперь и движение в сторону ИИ - является своего рода техническим прогрессом. И интересно узнать ощущения людей в том возрасте, на чьих глазах все это происходило. И как происходила адаптация.
Когда я вступил в сознательный и самостоятельный этап своей жизни (вуз) - почти все это уже было. На моем веку пока что - только появление чат гпт было революционным скачком.
UPD: я вполне осознаю, что чат гпт - это не ИИ, а «предсказатель следующего символа». Но это ощутимый сдвиг. Со временем, думаю человечество осилит AGI, и возможно даже я это увижу собственными глазами.
Так не только богатые делают - даже self employer может вычитать из налоговой базы кучу всего. Этим пользуются и уменьшают тем самым налог. Вот и получается -
яхтамашина на фирму.А чатом гпт пользуетесь? Какие в целом ощущения от технического прогресса?
Ну если грубо - зп 100 тр, на руки 87 (-13% ндфл), в ПФР и медстраховка еще 30% от 100 (там тоже есть ограничения в год и есть льготные категории компаний, в том числе ИТ)
Итого 130 ФОТ превращаются в 87 на руки, то есть на налоги уходит 43 тр - это еще ~0,5 зарплаты, если смотреть со стороны работника.
Такой декларации не существует. Есть декларация 3-НДФЛ - это за крупные продажи (машина, квартира, не всегда ее надо подавать) и доход из зарубежных источников.
Ого, 70 лет, 220к в год и мейнфреймы - вы тот самый вымирающий вид программистов, как кобольщики в банках?
Таки в том-то и посыл - чтобы работник в России видел весь или почти весь ФОТ (там как раз выходит примерно 40-50%) в платежках, так же как и работник в Канаде, и сам бы относил декларацию каждый год в налоговую.
Ну в айтишных кругах ходит прикол - чтобы получить реальное время выполнения задачи, надо первичную оценку, данную условным программистом, умножить на число пи (~3.14) и число е (~2.7). Так как оба числа являются иррациональными (так же как порой и сами задачи в стиле "Реализовать статусную модель") и отражают фундаментальные математические вещи, что позволяет увязать это с математикой и получить реальное число в часах/днях/месяцах.