На многих сайтах пароли предлагают менять каждые полгода, где-то чаще, где-то реже. Но делается это специально для защиты от слива баз и передачи пароля самим пользователем и прочим причинам. Биометрию же не поменять, она одна раз и навсегда, если она утечет, то использовать её более нигде не получится. А с учетом того, что даже самые-самые базы периодически утекают это всего лишь вопрос времени. ИТ-технологии должны дополнять, но! не заменять существующие важные системы. Бумажные документы не переделать, они такие какие выпущены, базы меняются без особых проблем, любой администратор это подтвердит. Если проще говорить, то ИТ должен ускорить READ-доступ к документам, но WRITE-доступ должен быть в бумажном виде всегда (паспорт, свидетельство, договор, доверенность). Возможно, в будущем, для некритичной части следует подумать открыть и WRITE, но делать очень-очень аккуратно и анализировать обратную связь .
Некоторые ритейлеры решили проблему по-другому. Оформили юр лица в странах где взаимодействие с государством проще и дешевле, открыли интернет-магазины и продают без всякого геморроя и доставляют со складов в России. Всё законно и профит. Тенденции российского законодательства последнее время направлены на усложнение/удорожание/ухудшение жизни людей, ККТ в текущем виде одно из них.
P.S. Вчера по телевизору опять передали слова Орешкина о том, что нынешнее ухудшение жизни людей благо для экономики. Она стала первичной, про людей забыли. Занавес.
Правильно ли я понял, вы делаете валидацию в нескольких местах (при получении запроса и при работе сервиса)? То, что может проверить доменный слой проверяет он, всё остальное на уровне Application.
Статья написана ни столько для простых смертных, сколько для того, чтобы понять кто-нибудь вообще в теме или нет. Таким образом можно понять размер сообщества и выявить конкурентов. Ну и конечно, поделиться знаниями.
Очень нужная вещь в языке. Стараемся использовать максимум из языка, type hint первый важный шаг. Теперь нужны генерики и структуры как в С. Поддержание нескольких подходов (например, динамическая/статическая типизация) и парадигм залог использования языка в будущем.
ORM и SQL это разные инструменты для работы с данными. Соответственно, применять их надо по назначению. Строить отчёты и делать выборки, это задача SQL, для этого он разработан. ORM нужен для записи и DDD.
Read model — SQL, write model — ORM.
На многих сайтах пароли предлагают менять каждые полгода, где-то чаще, где-то реже. Но делается это специально для защиты от слива баз и передачи пароля самим пользователем и прочим причинам. Биометрию же не поменять, она одна раз и навсегда, если она утечет, то использовать её более нигде не получится. А с учетом того, что даже самые-самые базы периодически утекают это всего лишь вопрос времени. ИТ-технологии должны дополнять, но! не заменять существующие важные системы. Бумажные документы не переделать, они такие какие выпущены, базы меняются без особых проблем, любой администратор это подтвердит. Если проще говорить, то ИТ должен ускорить READ-доступ к документам, но WRITE-доступ должен быть в бумажном виде всегда (паспорт, свидетельство, договор, доверенность). Возможно, в будущем, для некритичной части следует подумать открыть и WRITE, но делать очень-очень аккуратно и анализировать обратную связь
.
P.S. Вчера по телевизору опять передали слова Орешкина о том, что нынешнее ухудшение жизни людей благо для экономики. Она стала первичной, про людей забыли. Занавес.
Read model — SQL, write model — ORM.