Авторы: #EnriquezRene, #SalazarAlberto
Каждая организация в наши дни - это ИТ-организация, осознает она это или нет.
У каждой системы есть архитектура, о которой кто-то должен заботиться, вне зависимости от того, существует ли выделенная роль архитектора. Хорошая архитектура должна обеспечивать долгосрочный успех приложения или системы. Это можно сделать только при условии выполнения всех бизнес-требований. Соответственно, именно эти требования оказывают решающее влияние на архитектуру. Но есть два сценария нарушения:
- Выбираются средства, с которыми знакомы разработчики.
- Выбираются средства, которые сейчас на волне хайпа.
Более того, простого создания проекта архитектуры недостаточно. Архитектура должна быть общим знанием / достоянием команды, позволяя каждому участнику принимать согласованные с архитектурой решения в процессе своей деятельности.
Критерии качества архитектуры ПО
Процесс улучшения существующей архитектуры ПО иногда оказывается более интересным, чем создание новой с нуля. Так происходит, потому что с течением времени разработчики получают больше информации о бизнес-требованиях и о том, как приложение функционирует в промышленной эксплуатации.
Это перекликается с идеей “грязных” задач, Первые версии программ в любом случае окажутся неудачными.
Принципы построения архитектуры ПО
В сухом остатке - это Low coupling, high cohesion, то есть высокая связность кода внутри компонента (Компонент ПО - определение компонента) и низкая связанность компонентов между собой.
ПО конструируется из многих компонентов и вам не стоит переживать по поводу большого их количества.
Принципы проектирования на уровне исходного кода (SOLID)
Связи:
- Упоминаются книги по работе с бизнес-требованиями:
- Writing Effective Use Cases by Alistair Cockburn
- User Stories Applied by Mike Cohn
- Упоминается книга, связанная с CI: Infrastructure as Code by Kief Morris