Принцип DRY (не повторюй себе) зазначає, що "кожен предмет повинен мати єдине, однозначне, авторитетне представлення в системі". Більшість часу це стосується коду, але він часто поширюється і на документацію.
Кажуть, що кожна програмна система має архітектуру, вибирали ви її чи ні. Іншими словами, програмне забезпечення, яке ви будуєте, має структуру, і структура "як побудована" - це архітектура програмного забезпечення. Оскільки вбудована програмна система поставляється з архітектурою, чи створення опису архітектури цієї системи є порушенням принципу DRY? Зрештою, якщо вам потрібно знати архітектуру, ви завжди можете просто подивитися на код ...
Ви насправді вірите, що можете розпізнати архітектуру, подивившись на код? Код розповість про всі функціональні та нефункціональні вимоги, архітектурні компроміси, проблеми розгортання, бізнес-контекст, сценарії використання випадків тощо, тощо? Якщо ви в коді можете ПРАВИЛЬНО сказати вам це, це одне пекло тривіальної системи.
—
luis.espinal
@ luis.espinal, Можна відрізнити статичні та динамічні структури відповідно від коду та запущеної системи. Чи будуть ці структури еквівалентні архітектурі системи, залежатиме від вашої школи думки. Як ви вже зазначали, ви все одно не будете бракувати деяких великих фрагментів, включаючи будь-які архітектурні драйвери та обґрунтування дизайнерських рішень.
—
Майкл
Яка справжня школа думки прирівнює структури, похідні від коду, архітектурі системи? Якщо ми знаємо, що ми будемо пропускати кілька великих фрагментів, включаючи будь-які архітектурні драйвери, то нам не вистачає всієї архітектури. Це тривіально доводить, що статичні та динамічні структури, які можна відрізнити лише від коду, не представляють собою цілі архітектури (незалежно від школи думки.) Якщо ми подивимось на досить добре сформовані визначення систем та архітектури програмного забезпечення (тобто SEI або INCOSE), вони зрозумілі, що код є лише частиною архітектури.
—
luis.espinal
конкретний випадок. Архітектура системи може вимагати від мене розгортання на певній кількості машин, при цьому зовнішні інтерфейси вимикаються та включаються в певному порядку. Статичні та динамічні структури, отримані лише від коду, навряд чи зможуть зрозуміти, що (якщо взагалі є). Очевидно, однак, вони є частиною розгортання та експлуатаційних аспектів архітектури системи. І будь-яка структура, похідна від коду, стосуватиметься лише реалізації статичних аспектів архітектури програмного забезпечення (або компонента). Це ніколи не може бути для системної архітектури.
—
luis.espinal
@ luis.espinal, запрошую надіслати відповідь на це питання! Здається, ви представляєте прекрасну точку зору, що, на мою думку, додасть справжню цінність цій темі. Ви про це проповідуєте хору, то чому б не створити відповідь, яка повністю пояснює ваше мислення, щоб кожен мав користь? Ось чому я задав питання в першу чергу.
—
Майкл