
Чистая архитектура с Go
- Блог компании Конференции Олега Бунина (Онтико),
- Блог компании Space307,
- Высокая производительность,
- Программирование,
- Go
Меня зовут Эдгар (ZergsLaw), я работаю в компании, которая занимается финтех-разработкой для b2b и b2c. Когда только устроился в компанию, то попал в команду большого финтех-проекта и получил «в нагрузку» небольшой микросервис. Мне поручили его изучить и подготовить план рефакторинга, чтобы в дальнейшем выделить отдельную команду поддержки для сервиса.

«Мой» сервис — это proxy между определенными модулями большого проекта. На первый взгляд изучить его можно за один вечер и браться за дела поважнее. Но приступив к работе я понял, что ошибся. Сервис был написан полгода назад за пару недель с задачей протестировать MVP. Всё это время он отказывался работать: терял события и данные, или переписывал их. Проект перекидывали из команды в команду, потому что никто не хотел им заниматься, даже его создатели. Теперь стало ясно почему под него искали отдельного программиста.
«Мой» сервис — это пример плохой архитектуры и изначально неправильного проектирования. Все мы понимаем, что так делать нельзя. Но почему нельзя, к каким последствиям это приводит и как попытаться все исправить, я и расскажу.
Читать дальше →

«Мой» сервис — это proxy между определенными модулями большого проекта. На первый взгляд изучить его можно за один вечер и браться за дела поважнее. Но приступив к работе я понял, что ошибся. Сервис был написан полгода назад за пару недель с задачей протестировать MVP. Всё это время он отказывался работать: терял события и данные, или переписывал их. Проект перекидывали из команды в команду, потому что никто не хотел им заниматься, даже его создатели. Теперь стало ясно почему под него искали отдельного программиста.
«Мой» сервис — это пример плохой архитектуры и изначально неправильного проектирования. Все мы понимаем, что так делать нельзя. Но почему нельзя, к каким последствиям это приводит и как попытаться все исправить, я и расскажу.