«Наша команда з розробки дійшла висновку, що застосунок буде безпечнішим, аніж вебверсія.»
Неймовірно. Державні податкова служба, ПФУ, будь-який банк надають послуги через вебсайти і не вважають такий спосіб небезпечним.
«Друге — це вже питання зручності.»
Звичайно, ноутбук більш зручний, ніж смартфон.

«Чи можливе тимчасове припинення підприємницької діяльності (декретна відпустка, хвороба, виїзд за кордон та ін.)?
Законом та іншими нормативно-правовими актами не передбачено тимчасове припинення підприємницької діяльності.»
chp.com.ua/...​ba-vijizd-za-kordon-ta-in

А «відпустка» стосується лише першої і другої групи єдиного податку
«Відповідно до пункту 295.5 статті 295 ПКУ платники єдиного податку першої і другої груп, які не використовують працю найманих осіб, звільняються від сплати єдиного податку протягом одного календарного місяця на рік на час відпустки»
chp.com.ua/...​bo-vtratu-pratsezdatnosti

Не погоджуюсь. Класи сутностей JPA (entity classes) реалізують патерн Active Record на рівні репозиторія. Основна задача — відображення реляційної моделі на об’єктну. DTO використовуються для передачі даних від сервіса контролеру і далі клієнту. Можуть мати багато різновидів навіть для однієї сутності в залежності від характеру запиту. Це різні задачі, які вирішуються в різних частинах застосунку. Навіть якщо структури даних зовні схожі, це не є підставою вважати Active Record різновидом DTO.

Дуже вдячний.

«...якщо чесно, тут доволі поверхнево описуються ці два принципа»
:)
Дякую автору за корисний огляд. Сподіваюсь, він дозволить додати посилання на курс Роберта Мартіна, в якому поглиблено розглядаються SOLID принципи та багато інших цікавих речей ;)
Clean Code Fundamentals by Robert C. Martin
www.oreilly.com/...​ndamentals/9780134661742

«автор не рекомендує префікс I до інтерфейсів»
Так, тому що сучасна IDE може підказати, чи є тип класом або інтерфейсом. Досить складно розшифровувати hungarian notation, легше сприймаються звичайні слова і змістовні фрази.

«...а також з різновидом DTO — активні записи — Active Records — це ті ж DTO, але вони також мають навігаційни методи.»
Ні, це різні патерни для вирішення різних задач.
DTO для передачі даних, Active Record для доступу до запису в БД та ORM.
«This pattern is commonly used by object persistence tools and in object—relational mapping (ORM).» en.wikipedia.org/...​iki/Active_record_pattern

звичайні вади. напевно, не завжди слід перекладати дослівно.

нагадує CAP теорему.
правда, дивно, як неймовірна експертиза із глибокими знаннями може поєднуватись із низькою ціною.

Software development

ні, посилання surl.li/luekt веде на сторінку послуг вебхостінгу і VPN

ну почему же только с зарубежными юрлицами? с любыми юрлицами, в первую очередь с отечественными компаниями-работодателями, которые оформляют работников как предпринимателей.

мне кажется, EPAM тоже проводит тренинги по Hybris.

думаю, поєднувати опис типів міжпроцесного обміну і документування в одній невеличкій статті не було вдалою ідеєю.
то все заради GraphQL?
і, до речі, дуже дивне визначення архітектури як на мене.

интересная статья.
правда, один исполнитель на проекте — всегда повышенный риск.
видимо, в вашем случае продукт был почти готов и его характер не был критичным.

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

я слышал, многие компании рассматривают собственную бизнес-модель как конкурентное преимущество на рынке. вы полагаетесь на открытость, точность, объективность представителей заказчика и не изучаете бизнес непосредственно на месте?

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

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

спасибо.
особенно полезными мне показались замечания о культурных отличиях.

принцип Лісков — про властивості і поведінку класів, а не про методи (операції) інтерфейсу. Не варто пробувати пояснити контракт класу через його інтерфейс, бо вони не тотожні. До того ж, методи можуть бути опціональними, якщо про це явно оголошено в контракті (наприклад, add/set/remove в java.util.ListIterator).

„клас-нащадок не має додавати ніяких умов до виконання методу і після виконання методу”
нащадок може послаблювати передумову і підсилювати післяумову та
інваріант: „Subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them).”
en.wikipedia.org/wiki/Design_by_contract
Наприклад, в Java метод нащадка може повертати підтип результату перевизначеного ним метода базового класу: „The return value of a method of the subclass needs to comply with the same rules as the return value of the method of the superclass. You can only decide to apply even stricter rules by returning a specific subclass of the defined return value, or by returning a subset of the valid return values of the superclass.”
stackify.com/...​ov-substitution-principle