С кодом работать проще, так как для него есть инструменты и работу с ним проще автоматизировать. Если вы можете легко переходить между представлениями, связанным со сценариями, будет проще погружаться в проект (это важно, если необходимо взаимодействие с большим количеством команд) и это проще для архитектора, так как становится не только внешним инструментом, но и внутренним.
AaC – это не только инструмент архитектурного надзора над кодом, который разрабатывают программисты, но в большей степени альтернативный способ проектирования архитектуры, который дает архитектору дополнительные возможности. В частности:
Синхронное версионирование архитектурной модели и кода.
Смещение фокуса с оформления на проектирование, в т.ч. непротиворечивой, модели.
Автоматизированном формировании артефактов, необходимых различным ЗЛ.
Автоматическое выполнение нормативных требований (регламентов и практик, принятых в компании).
Не обязательно применять подходы с контролем кода при внедрении AaC. Оверхэд будет, если процессы проектирования не выстроены и вновь спроектированные (под)системы сразу становятся «легаси». Если же процессы проектирования и разработки достаточно регламентированы, то подходы AaC будут только помогать делать процесс проектирования в соответствии с нормами, принятыми в компании.
По вопросам публикации своих решений и получения обратной связи вам необходимо проконсультироваться со специалистами нашей стажировочной программы. Пожалуйста, направьте ваш запрос на почту: practice@infotecs.ru.
Наш процесс разработки не основывается на архитектуре, а включает ее как один из важных этапов, наряду с планированием, анализом бизнес и системных требований, проектированием UI и т.д. Процесс разработки предваряет подготовительная фаза с определением целей и конечного результата.
Вот, интересно, можно ли было сделать предметом своей статьи на Хабре разбор какой-нибудь Вашей задачи?
Спасибо за идею) Мы можем сделать разбор задачи, но не для этого блога, а для канала стажировочной программы ИнфоТеКС.
1. Что значит "согласованную"? Непротиворечивую?
Да, верно. То есть обеспечить отсутствие противоречий между различными архитектурными артефактами.
2. Зачем смещать фокус? Разве одно другому не противоречит, не дополняет?
Чтобы затрачивать меньше времени на компоновку диаграммы и больше времени на продумывание архитектуры, так как нам больше интересна сама архитектурная модель, а не способ ее представления (соблюдение требований нотации). Это позволит сконцентрироваться на том, как должна работать система.
3. Что такое "артефакт"?
Все, что отдается на ознакомление различным заинтересованным лицам (аналитикам, менеджерам, бизнесу). Архитектор описывает модель, а из нее генерируются различные представления, понятные ЗЛ.
С кодом работать проще, так как для него есть инструменты и работу с ним проще автоматизировать. Если вы можете легко переходить между представлениями, связанным со сценариями, будет проще погружаться в проект (это важно, если необходимо взаимодействие с большим количеством команд) и это проще для архитектора, так как становится не только внешним инструментом, но и внутренним.
AaC – это не только инструмент архитектурного надзора над кодом, который разрабатывают программисты, но в большей степени альтернативный способ проектирования архитектуры, который дает архитектору дополнительные возможности. В частности:
Синхронное версионирование архитектурной модели и кода.
Смещение фокуса с оформления на проектирование, в т.ч. непротиворечивой, модели.
Автоматизированном формировании артефактов, необходимых различным ЗЛ.
Автоматическое выполнение нормативных требований (регламентов и практик, принятых в компании).
Не обязательно применять подходы с контролем кода при внедрении AaC. Оверхэд будет, если процессы проектирования не выстроены и вновь спроектированные (под)системы сразу становятся «легаси». Если же процессы проектирования и разработки достаточно регламентированы, то подходы AaC будут только помогать делать процесс проектирования в соответствии с нормами, принятыми в компании.
Стек и методика AaC никак не связаны.
По вопросам публикации своих решений и получения обратной связи вам необходимо проконсультироваться со специалистами нашей стажировочной программы. Пожалуйста, направьте ваш запрос на почту: practice@infotecs.ru.
Наш процесс разработки не основывается на архитектуре, а включает ее как один из важных этапов, наряду с планированием, анализом бизнес и системных требований, проектированием UI и т.д. Процесс разработки предваряет подготовительная фаза с определением целей и конечного результата.
Спасибо за идею) Мы можем сделать разбор задачи, но не для этого блога, а для канала стажировочной программы ИнфоТеКС.
Да, верно. То есть обеспечить отсутствие противоречий между различными архитектурными артефактами.
Чтобы затрачивать меньше времени на компоновку диаграммы и больше времени на продумывание архитектуры, так как нам больше интересна сама архитектурная модель, а не способ ее представления (соблюдение требований нотации). Это позволит сконцентрироваться на том, как должна работать система.
Все, что отдается на ознакомление различным заинтересованным лицам (аналитикам, менеджерам, бизнесу). Архитектор описывает модель, а из нее генерируются различные представления, понятные ЗЛ.