Цей жарт зробив мій день ))

Вибачте за стиль, я просто намагався писати «цікаво» (щоб зацепити). В мене не було мети «знецінення» іншого бачення, яке не співпадає з моїм! Я лише хотів сказати: «я роблю ось так, для досягнення таких цілей...»
Просто мінусом текстового контенту є те, що читач не завжди може оцінити «емоційне» забарвлення цього тексту. Тому багато жартівливих моментів (як я собі напочатку задумав) можна трактувати як агресивне подання матеріалу. Я обов’язково врахую це в наступний раз.

Не піценосів, а фізруків, попрошу ))

1. В вашому прикладі з locals, ви задаєте «дефолтное значение, которое определяется на основании других переменных», або даєте можливість передати кастомне значення.... Тобто ви пеередаєте кастомне значення в «child» модуль, яке ВЖЕ згенерували в «root» модулі? По факту робите так, як я раджу в статті (але не завжди)?
Тоді чому б не викинути ці locals з «child» взагалі, і не перенести їх в «root» модулі, якщо ви все рівно в «специфічних» випадках виносите їх генерування в «root» ?
Я все ж впевнений, що це спростить розуміння логіки коду.

2. Згоден, це сугубо суб’єктивно. Для мене мій варіант здається «зрозумілішим» (наприклад, для людини, яка онбордиться на проект)

3. Ви знову ж таки передаєте ВЖЕ готове значення для «some_var_changed_by_1%_of_child_modules_bool», яке було згенероване в «root» модулі (або ж ставите дефолтне значення, якщо такого немає). Ви не генеруєте значення для пропертів ресурсів в locals «child» модулю, ви лише вказуєте дефолтне значення (що ніяк не суперечить моєму підходу). Але це тяжче читати....
Ну правда, це ви опишете близько 15 lookup-пів ? І як це виглядатиме?
Це звісно суб’єктивно, знову ж таки....

P.S: знов повторюсь, що я не претендую на звяння мессії Тераформу. Я лише описую як роблю я, і для чого я так роблю.

Зовсім забув, ще є така штука як «(optional)» в описаннях variables — це щодо того, як можна одночасно «приймати» одним модулем різні об’єкти з різною кількістю пропертів в них.

1. В «ternary operator» є лише «true» або «false», так? Тобто лише два варіанти ? А якщо треба більше?
2. Що на рахунок «readability» такого підходу? Це полегшує читання коду?
3. Що робити якщо ти в «child» модулі маєш прийняти мапу об’єктів, де у кожного об’єкту по 15-20 пропертів (наприклад, ти хочеш створювати таку махіну як FrontDoor з усіма origins, routing rules, WAF і т.д (реальний кейс з мого досвіду), і мати модуль, який би передбачав можливість деплою FrontDoor за допомогою платформи (Platform engineering), яка ВЖЕ деплоїть більше 10 кастомерів, що потребують кожен «свого унікального» FrontDoor, зі своїми унікальними вимогами і значеннями до нього? Теж використовувати «ternary operator»? Як це реалізувати щоб не потрапити в дурку?

Так, ви праві — версіонування модулів вирішує цю проблему.
Але мій приклад більше про збільшення «flexibility» модулю, щоб він міг приймати і створювати більшу «різноманітність» ресурсів.

P.S: і я ж не кажу, що немає інших альтернатив. Я кажу: «я роблю ось так для досягнення того-то».

1. «прошу уточнити де в офіційній документації згадано що використання count deprecated або це bad practice?» — якщо ви читали мою статтю трохи далі, то я якраз цитую офіційну документацію, де про це згадано. До речі, в посиланні, що ви скинули, теж є про це в останньому абзаці ))

2. З приводу «не зʼясувавши причин чому було щось зроблено так або інакше» — наведіть хоч один приклад/аргумент для використання «count» замість «for_each». Іншими словами: є хоч один кейс, коли ти не зможеш реалізувати щось з «for_each», але зможеш реалізувати з «count»? Які його «переваги» в порівнянні з «for_each» ?

3. Інкапсуляція є механізмом об’єднання данних, методів та атрибутів в об’єкти, з подальшою можливістю(не завжди) скриття цих методів чи об’єктів від зовнішнього світу. І основною причиною для інкапсуляції є: «Essentially, encapsulation prevents external code from being concerned with the internal workings of an object». Тобто, щоб на данні об’єкта не можна було ніяк впливати окрім як із середини самого об’єкту.
По-перше, Тераформ не є ООП мовою програмування, в нього немає классів, методів і т.д.... Якщо ви хочете заперечити, що для інкапсуляції не є обов’язковим ООП — так, це правда, але Терраформ НЕ є не тільки ООП мовою програмування, але й взагалі НЕ є мовою програмування. Тож, цікаво, яке значення інкапсуляції ви вкладаєте в «інкапсуляцію в Тераформ»? Є якесь визначення з офіційних джерел про «інкапсуляцію в Тераформ» ?
По-друге, навіть якщо ми припустимо, що існує якась «інкапсуляція в Тераформ», і вона полягає з ваших слів в «загорнути в середину модуля трохи логіки щоб розрулити вхідні дані різного типу», то яким чином мій підхід заважає вам приймати модулем об’єкти/мапи об’єктів, або значення «locals» різних типів і «розрулювати» їх як ви вважаєте за потрібне?
Моя концепція, насамперед, полягає у формуванні неймінгу чи значень пропертів в «root» модулях, і передачі цих фактичних значень в «child» (це як передавати аргументи в функцію чи в створення об’єкту класу, якщо ви любите аналогії з програмуванням). А що ви вже далі будете з тими значеннями робити — ваша справа. Ви можете одночасно приймати об’єкти з 10 параметрами всередині, і об’єкти з 5 параметрами, але при цьому і ті, і ті будуть «прийняті» вашим «child» модулем, якщо ви опишете, що вони їх можуть приймати (default «" значення ще ніхто не відміняв). Чули щось про «duck typing» та «interfaces» в програмуванні ? Я намагаюсь досягнути саме такого ефекту!
Це робить ваші модулі більш «flexible» в плані різноманітності ресурсів, які вони зможуть створювати.

Так, я якраз про проблеми його використання і говорив!)

Наявність класів не є обов’язковою вимогою для того щоб використовувати ООП.
В GO більше ООП чим в більшості мов програмування з класами

А чому «опустили»? По-перше, «війти в айті» девопсам точно легше через меншу конкуренцію (і плювати на поріг входу). Я думаю, автор коменту саме це мав на увазі. А по-друге..., чи багато девопсів можуть дійсно писати код з ООП, а не лише скріптіки на Python? Не думаю, що Yaml-девелоперство і Terraform-задротство це саме те, як Google уявляє і описує людину, що займається DevOps практиками, в своїй книзі «Site Reliability Engineering».
Девопс описаний в книжках, і девопс, що закриває потреби бізнесу в реальному світі — то різні люди!)

Дякую)
А через 2 роки.... я вже може буду магістром з профільною освітою.... ))

Курси про те, як тикатись немов сліпе кошеня, і пробувати поки не вийде?
Не думаю, що такі курси комусь зайдуть. То радше філософія самурая аніж конкретний план для дій)

Сам в шоці.
Вони ще й обидва з профільною освітою ))