Коротка історія: Що має робити архітектор?

Ця стаття — коротке оповідання, яке імітує Q&A, і автор використовує гумористичний стиль, щоб коротко проаналізувати роботу архітекторів: Я хочу бути архітектором програмного забезпечення.

Це чудовий варіант для молодих розробників програмного забезпечення.

Я хочу керувати командою і приймати важливі рішення щодо баз даних і фреймворків, вебсерверів тощо.

О, тоді взагалі не варто бути архітектором програмного забезпечення.

Звісно, я хотів приймати важливі рішення.

Це нормально, але ви не включаєте важливі рішення у свій список, які не мають значення.

Що ти маєш на увазі? Ви хочете сказати, що бази даних — це не важливі рішення, чи знаєте ви, скільки ми на них витрачаємо?

Можливо, це коштує занадто дорого. Однак бази даних не є одним із найважливіших рішень.

Як ти можеш так казати? База даних є ядром системи, де всі дані систематизуються, класифікуються, індексують і отримують доступ. Без бази даних не було б системи.

База даних — це просто пристрій введення, який надає корисні інструменти для класифікації, запитів і інформаційної звітності, але це лише допоміжні функції архітектури системи.

Допомога? Це обурливо.

Саме так, це допоміжна. Бізнес-правила системи можуть використовувати деякі з цих інструментів, але ці інструменти не є притаманними відповідним бізнес-правилам. За потреби можна замінити існуючі на інші інструменти; І бізнес-правила не зміняться.

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

Ось у чому твоя проблема.

Що ти маєш на увазі?

Ваша проблема в тому, що ви думаєте, ніби бізнес-правила залежать від інструментів баз даних, але це не так. Або принаймні, так не повинно бути, поки не буде надано хорошу архітектуру.

Це просто божевілля. Як створити бізнес-правила, які не використовують ці інструменти?

Я не кажу, що вони не використовують інструменти бази даних, але вони не залежать від них. Бізнес-правила не повинні знати, яку базу даних ви використовуєте.

Отже, як отримати бізнес-правила, не знаючи, які інструменти використовувати?

Інвертуйте залежності так, щоб база даних залежала від бізнес-правил. Переконайтеся, що бізнес-правила не залежать від бази даних.

Ти говориш нісенітниці.

Навпаки, я використовую мову програмної архітектури. Це принцип інверсії залежності: низькорівневі стандарти мають спиратися на високорівневі стандарти.

Нісенітниця! Критерії високого рівня (припускаючи посилання на бізнес-правила) Виклик низькорівневих критеріїв (припускаючи посилання на бази даних). Отже, критерій високого рівня залежить від критерію низького рівня згідно з принципом, що абонент залежить від абонента. Всі це знають!

Це справедливо під час виконання. Але при компіляції ми хочемо інверсію залежностей. Вихідний код високорівневих рекомендацій не повинен містити згадку про вихідний код низькорівневих рекомендацій.

Давай! Як можна зробити дзвінок, не згадавши про це?

Звісно, без проблем. Ось що таке об'єктно-орієнтована.

Об'єктно-орієнтація — це створення реальних моделей, поєднання даних, функціональності та цілісних об'єктів. Йдеться про організацію коду в інтуїтивну структуру.

Так кажуть?

Як ми всі знаємо, це очевидна правда.

Так, це можливо, але при використанні об'єктно-орієнтованих рекомендацій справді можливо викликати їх без згадки.

Ну, як це зробити?

У об'єктно-орієнтованому дизайні об'єкти надсилають повідомлення один одному.

Звісно, це правда.

Коли відправник надсилає повідомлення, він не знає типу отримувача.

Це залежить від мови. У Java відправник знає принаймні базовий тип отримувача. У Ruby відправник принаймні знає, що отримувач здатен обробляти отримані повідомлення.

Саме так. У будь-якому разі, відправник не знає конкретного типу отримувача.

Саме так, це так.

Отже, відправник може спроектувати приймач для виконання певної функції, не вказуючи конкретний тип приймача.

Саме так, саме так. Я розумію. Однак відправник все одно залежить від отримувача.

Це справедливо під час виконання. Однак при компіляції це інакше. Вихідний код відправника не згадує і не залежить від вихідного коду отримувача. Насправді вихідний код отримувача залежить від вихідного коду відправника.

Нізащо! Відправник все одно залежить від класу, який він надсилає.

Можливо, з якогось вихідного коду все стане зрозуміліше. Наступний абзац написаний на Java. Перший — відправник:

Ось приймач:

Примітка: Receiver залежить від відправника, SpecialReceiver залежить від відправника, і в відправнику немає інформації, пов'язаної з отримувачем.

Так, але ти брешеш, ти встановив інтерфейс приймача в клас відправника.

Ти починаєш розуміти.

Що ти знаєш?

Звісно, це принцип архітектури. Відправник має інтерфейс, який отримувач має реалізувати.

Якщо це означає, що доведеться використовувати вкладені класи, то ......

Вкладені класи — це лише один із засобів досягнення мети, є й інші способи.

Зачекай хвилинку. Яке це має відношення до баз даних? Ми почали говорити про бази даних.

Давайте трохи більше розглянемо код. Перше — це просте бізнес-правило:

Бізнес-правила не мають великої ваги.

Це лише один приклад. Може бути більше таких класів, які реалізують багато різних бізнес-правил.

Отже, що ж таке Gateway?

Він надає всі методи доступу до даних через бізнес-правила. Реалізуйте його наступним чином:

Примітка: Це в бізнес-правилах.

Добре, що таке клас «Щось»?

Вона представляє простий бізнес-об'єкт. Я розміщую його на сутності.

Зрештою, реалізація BusinessRuleGateway, цей клас знає справжню базу даних:

Крім того, зверніть увагу, що бізнес-правила викликають базу даних під час виконання; Однак під час компіляції база даних залучає та залежить від businessRules.

Ну, здається, я зрозумів. Ви просто використовуєте поліморфізм, щоб приховати факт, що база даних реалізована, від бізнес-правил. Однак інтерфейс все одно необхідний для забезпечення всіх інструментів бази даних для бізнес-правил.

Ні, зовсім ні. Ми не намагалися впровадити інструменти бази даних для бізнес-правил. Натомість вони використовують бізнес-правила для створення інтерфейсів для своїх потреб. Реалізація цих інтерфейсів дозволяє викликати потрібні інструменти.

Так, але якщо потрібно використовувати всі інструменти для всіх бізнес-правил, просто вставте інструмент у інтерфейс шлюзу.

Ах, здається, ти ще не розумієш.

Зрозуміти що? Це вже зрозуміло.

Кожне бізнес-правило визначає лише один інтерфейс для інструментів доступу до даних, які йому потрібні.

Зачекай, що скажеш?

Це принцип розділення інтерфейсів. Кожен клас бізнес-правил використовує лише певні можливості бази даних. Отже, інтерфейси, які надає кожне бізнес-правило, можуть отримувати доступ лише до відповідних об'єктів.

Однак це означає, що існує багато інтерфейсів і невеликих класів реалізації, які викликають інші класи бази даних.

Чудово, ти починаєш розуміти.

Але це надто заплутано і марна трата часу. Навіщо це робити?

Це організовано і економить час.

Давай, купи багато коду заради самого коду.

Навпаки, нерелевантні рішення можуть бути відкладені через важливі архітектурні рішення.

Що це значить?

Пам'ятаю, на початку ти казав, що хочеш стати архітектором програмного забезпечення, чи не так? Ти хочеш приймати всі рішення, які справді мають значення.

Так, я так і думав.

Ви ж хочете приймати рішення щодо баз даних, вебсерверів і фреймворків, так?

Так, ти кажеш, що це не має значення. Просто нерелевантний контент.

Саме так. Ось і все. Важливі рішення, які приймають архітектори програмного забезпечення, — це ті, що дозволяють вам приймати рішення щодо баз даних, вебсерверів і фреймворків.

Але спочатку треба вирішити, які саме!

Ні, це не працює. Насправді їх можна вирішити пізніше в циклі розробки, коли інформації буде більше.

Це катастрофа, якщо архітектори заздалегідь визначають фреймворки, але виявляють, що вони не забезпечують потрібну продуктивність або вводять нестерпні обмеження.

Лише коли архітектор вирішує відкласти рішення, він приймає рішення, коли інформації достатньо; Команди, які не використовують повільні та ресурсомісткі IO-пристрої та фреймворки, можуть створювати швидкі, легкі тестові середовища на розсуд архітекторів. Тільки його архітектори дбають про те, що справді важливо, і затримують тих, хто не має значення, і саме такій команді пощастило.

Нісенітниця, я зовсім не розумію, що ти маєш на увазі.

Ну, уважно перегляньте цю статтю, інакше доведеться чекати ще 10 років, щоб розібратися.