Спасибо за интересную статью. Чуток покритикую :-) На мой взгляд структура выглядит слабо и не нормализовано. Это специально для статьи? Если да - то ок. А иначе, чуть разовью мысль. Если мы начинаем говорить про ddd и моделирование предметной области то надо четко отделять объекты от того как мы их видим.
Пример: Вам дали пачку денег и попросили составить реестр купюр. Вряд ли вы будете делать пометки прямо на банкнотах. Вы составите отдельный список. И будете в него записывать номера, номиналы и т.п. Если вас попросят рассортировать купюры по номиналу - то опять, сами купюры останутся неизменны - во просто положите их в разные кучки. И тут важно что кучка хранит в себе банкноту а не наоборот. С оборудованием тоже самое. Если вы описываете объект станок - то это объект сам по себе вес, производитель и т.п. А его включение в иерархии - это отдельно. Представьте, что у вас есть два абсолютно одинаковых станка. Тогда уместно хранить описание станка отельной таблицей. А экземпляры, где будет серийный номер, дата производства и т.п - отдельно. Если кто-то провидите ревизию станков - то это отдельный реестр кто, когда, состояние и т.п. Но сам Станок существует не зависимо от того есть о его учете запись в БД или нет.
У синтаксиса в стиле Query, на мой взгляд, самый большой недостаток это его похожесть на SQL. Эта похожесть путает тех кто знает SQL. Помечтаю немного, но было бы круто если бы Query синтаксис хотя бы для простых конструкций полностью совпадал бы с sql.
Основная идея в том, чтобы разработчик, получив примерное описание теста не мучился а сразу мог его закодить. И чтобы сам код теста и был его описанием. Тогда результаты теста будут читаемы, сам тест написан на том же языке что и ведется разработка (в моём случае C#), параметризованные тесты параметризуются объектами а не строками. Тестовый фремворк - не ещё один а тот же самый что и в основном проекте. (В примере xUnit)
Схема складывания крыльев довольно интересная. Но возникает ощущение что переусложнена.
Мне кажется что одно поворачивающееся крыло было бы во многом более эффективно/надёжно/безопасно… (IMHO).
Например во такое: www.aliexpress.com/i/32451805480.html
Мысль: Переименуем хаб «здоровье гика» в просто «здоровье»?
Мотивация: Чтобы медиков словом гик не пугать и не гикам тоже интересно было.
P.S. У когото были схожие мысли и хаб уже называется просто healh а не geekHealh.
Немного оффтопика:
Меня немного смущает то, что существование юзера в коде проверяется по имени и!!! паролю. Т.е. два одинаковых юзера с разными паролями — это ок? Наверное проверка существования должна быть только по имени.
Предложение.
Сделайте программирование CI/DI etc на многих языках.
Что-бы те кто в сновном программируют на языке Х — на нём же и делали CI/DI.
Вроде бы выглядит не сложно но по факту вместо единой системы появилась ещё одна для любителей котлина.
В тему: когда-то давно во время очередного холивара на тему как правильно что-то там изобразить в uml диаграмме, я услышал фразу:
"Не надо недооценивать силу простого текстового комментария". Вопрос-предложение: почему бы не увлекаясь формальностями, явно не писать в pr что именно вы хотите от ревьювера?
Спасибо за интересную статью. Чуток покритикую :-) На мой взгляд структура выглядит слабо и не нормализовано. Это специально для статьи? Если да - то ок. А иначе, чуть разовью мысль. Если мы начинаем говорить про ddd и моделирование предметной области то надо четко отделять объекты от того как мы их видим.
Пример: Вам дали пачку денег и попросили составить реестр купюр. Вряд ли вы будете делать пометки прямо на банкнотах. Вы составите отдельный список. И будете в него записывать номера, номиналы и т.п. Если вас попросят рассортировать купюры по номиналу - то опять, сами купюры останутся неизменны - во просто положите их в разные кучки. И тут важно что кучка хранит в себе банкноту а не наоборот. С оборудованием тоже самое. Если вы описываете объект станок - то это объект сам по себе вес, производитель и т.п. А его включение в иерархии - это отдельно. Представьте, что у вас есть два абсолютно одинаковых станка. Тогда уместно хранить описание станка отельной таблицей. А экземпляры, где будет серийный номер, дата производства и т.п - отдельно. Если кто-то провидите ревизию станков - то это отдельный реестр кто, когда, состояние и т.п. Но сам Станок существует не зависимо от того есть о его учете запись в БД или нет.
И пара вопросов про детали:
Как поступаете если в объекте есть большой список? Грузите его всегда? Или делаете частично загруженные объекты? (How Incomplete DDD Aggregates Can Improve Application Performance )
Используете ли строго типизированные ID? (How Strongly Typed IDs Can Make Your Code More Expressive)
У синтаксиса в стиле Query, на мой взгляд, самый большой недостаток это его похожесть на SQL. Эта похожесть путает тех кто знает SQL. Помечтаю немного, но было бы круто если бы Query синтаксис хотя бы для простых конструкций полностью совпадал бы с sql.
Еще неплохо помогает обычное машинное масло...
Спасибо за статью! Проделана огромная работа!
Добавлю свои 5 копеек про шуточный калькулятор на регулярках! Fun with C# Regex based Expression calculator - DEV Community 👩💻👨💻
Сделал очень похожую систему. Жаль что эту статью увидел уже после того как сделал. Вот описание моего решения. Дмитрий Дорогой и его PET Проект по мониторингу отопления на даче (газового котла) - YouTube
Что автор думает по поводу тангенционального тонарма?
Мне очень нравится когда тест(описание) и код теста не разъезжаются по разным языкам/репозиториям/средам/программам и т.п. Бонус: Я накидал своё видение подобных тестов вот тут DimonSmart/LikeSpecFlow: Small demo, how to write tests specflow like (github.com)
Основная идея в том, чтобы разработчик, получив примерное описание теста не мучился а сразу мог его закодить. И чтобы сам код теста и был его описанием. Тогда результаты теста будут читаемы, сам тест написан на том же языке что и ведется разработка (в моём случае C#), параметризованные тесты параметризуются объектами а не строками. Тестовый фремворк - не ещё один а тот же самый что и в основном проекте. (В примере xUnit)
Мне кажется что одно поворачивающееся крыло было бы во многом более эффективно/надёжно/безопасно… (IMHO).
Например во такое: www.aliexpress.com/i/32451805480.html
Мотивация: Чтобы медиков словом гик не пугать и не гикам тоже интересно было.
P.S. У когото были схожие мысли и хаб уже называется просто healh а не geekHealh.
:-(
Мне очень нравятся статьи с рассуждениями а не только с безопеляционными утверждениями.
Меня немного смущает то, что существование юзера в коде проверяется по имени и!!! паролю. Т.е. два одинаковых юзера с разными паролями — это ок? Наверное проверка существования должна быть только по имени.
Сделайте программирование CI/DI etc на многих языках.
Что-бы те кто в сновном программируют на языке Х — на нём же и делали CI/DI.
Вроде бы выглядит не сложно но по факту вместо единой системы появилась ещё одна для любителей котлина.
В тему: когда-то давно во время очередного холивара на тему как правильно что-то там изобразить в uml диаграмме, я услышал фразу:
"Не надо недооценивать силу простого текстового комментария". Вопрос-предложение: почему бы не увлекаясь формальностями, явно не писать в pr что именно вы хотите от ревьювера?