Архитектура приложения основанная на компонентах
Разбираясь в вопросах конструирования нового приложения, я снова искал новые подходы. И я нашел сначала Clean Architecture. Она мне понравилась. Основываясь на ее идеях я стал думать как организовать код в нашем приложении на GO. Тут мне попались несколько источников в итоге давших направление на компонентное деление. Можно еще делить по слоям, по функциям, но это все дает слишком много воли разработчиком, можно в одной фиче взять обратиться к хранилищу другой минуя, например, бизнес правила - это допустимо, но в будущем приводит к большой связанности и путанице.
Во-первых, о компонентной структуре пишет Uncle (Стив Мартин) в своей книге «Clean Architecture - A Craftsman's Guide to Software Structure and Design». Да о ней написано, но конкретных примеров пощупать нет.
Во-вторых, есть интересное сравнение производства ПО из компонентов с автомобильным производством.
Это меня подтолкнуло к использованию этой модели. Действительно мы можем разделить работу по компонентам, а при необходимости выносить эти компоненты в отдельные приложения микросервисы, особенное если внутри монолита у нас используется шина для обмена сообщениями.
Несколько статей и пример кода
Package by component and architecturally-aligned testing - Coding the Architecture
Package by component and architecturally-aligned testing - Coding the Architecture
www.codingthearchitecture.com
techtribes.je - containers - Coding the Architecture
techtribes.je - containers - Coding the Architecture
www.codingthearchitecture.com
An architecturally-evident coding style - Coding the Architecture
An architecturally-evident coding style - Coding the Architecture
www.codingthearchitecture.com
techtribesje/techtribesje
Source code for the techtribes.je website. Contribute to techtribesje/techtribesje development by creating an account on GitHub
github.com
Еще собираюсь применить технику EventStorming для определения модели разрабатываемого ПО, это новая идея для меня - в основе тут анализ событий проходящих в системе, они являются началом в этом методе, т.е. если мы обычно придумываем части системы, а потом как они общаются и какие сообщения (потоки данных) между ними двигаются, то тут мы идем наоборот в обратную сторону. Напишу позже пояснения для себя...