Из множества имеющихся вариантов я выбрал микросервисную архитектуру как ту, которая очень просто масштабируется и естественным образом обеспечивает разделение зон ответственности.
Главное приемущество микросервисов - это независимый деплой, что позволяет нескольким командам работать над разными частями системы не мешая друг другу и применение разных языков программирования. Масштабировать нагрузку можно и в монолите просто повышая количество инстансов. Разделять зону ответственности можно внутри одного кода. Просто разбивая код на модули и классы. Тут микросервисная архитектура ни причем. Какой размер команды и сколько команд занимается поддержкой этой системы?
Кажется монолитная архитектура тут подошла бы лучше, остается больше пространства для маневра и поскольку система молодая, не совсем очевидно что такое разделение правильное, всегда можно потом разбить её на микросервисы когда станет понятней где проходят границы разных частей системы.
А в чем проблема? Если код написан хорошим программистом, то он читается легко и легко поддерживается.
Если в проекте сложно разобраться, то это значит что программист оказался все таки не так хорош, и не смог написать код в терминах бизнеса, выделить слой прикладной области, выбрал слишком сложную архитектуру и т.д.
но когда есть сомнения — значит наследования не нужно
я согласен, об этом и говорится в заметках. Понятное дело, что от наследования бывает польза. Просто пример с фруктами очень простой. Часто не так очевидно, что наследование здесь подходит. Поэтому и нужно быть с ним очень осторожными. От неправильного использования наследования может сильно усложниться код.
Проблема в том, что если у вашего фрукта 100500 наследников, то при изменении фрукта, может непредсказуемо измениться поведение какого нибудь из наследников. И тогда придется переделывать ещё и их.
Конечно бывают понятные примеры, когда можно использовать наследование, но это часто не так. Например, стоит ли делать родительский класс для репозиториев сущностей из базы данных? А если у дочернему классу не нужны методы родителя? Скорее всего нет.
Мои заметки возможно действительно выглядят как набор советов, но какой смысл описывать всю систему знаний.
Если я начну все это расписывать, то ещё одна книга получится. Если вам это правда интересно, прочтите книгу.
С практической точки зрения, чтобы уменьшить сложно не нужно её измерять. Достаточно понимать, что один подход в решении проще другого. У сложности есть множество граней, их автор и показывает. В чем то код может быть сложнее, а в чем то проще. Меньше зависимостей — это проще, поэтому если я могу их уменьшить, значит я уменьшаю сложность.
Насчет стройки и недосыпа, автор в книге же четко написал
Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
Т.е. он пишет про сложность связанную со структурой IT системы.
Проще — значит менее сложно. Я в этих заметках описал что значит сложно через то, как она проявляется и по какой причине возникает.
Проще, значит разработчику легче работать с этим кодов в будущем, легче его понять, меньше и быстрее переделывать и меньше ошибок возникнет в процессе использования модулей. Автор приводит много примеров разных ситуаций когда можно сделать проще.
В том то и смысл, чтобы искать решение, при котором связей между модулями будет меньше. Иначе придется поддерживать больше кода, при изменении кода в одной части, исправлять другую.
Простой интерфейс и реализация — это не бред. Сам часто встречаю в пулл реквестах слишком сложный интерфейс, когда например передают лишние данные в метод. Или приходится всегда вызывать несколько методов по очереди у одного объекта, хотя можно было сделать только один.
С реализацией тоже самое. Например, бывает иногда добавляют проверки, которые никогда не сработают. И зачем тогда они нужны, в них придется больше вникать при попытке понять реализацию и возникнет больше вопросов, почему это здесь.
На самом деле да, нужно просто писать проще. Очень банально, но этого и не хватает для хорошего дизайна. А уже как писать проще, об этом книга.
Спасибо. Учту это в своих будущих статьях.
1) В концовке я написал, что он подходит для больших проектов говоря об этом в контексте использования интерфейсов, поэтому я указал, что
Язык GO кажется подходящим инструментом
а не написал, что он точно является подходящим.
2) Я старался показать именно сильные стороны, показывая разницу с самым распространенным способом работы с интерфейсами в популярных языках как Java, C++, PHP. Но видимо да, нужно было привести примеры с других языков, чтобы было понятнее.
Видимо, нужно писать подробнее, раскрывая больше мыслей. Чтобы не было таких недопониманий и негативных реакций. Это моя первая статья на хабре.
Согласен что возможно большое пересечение методов. Возможно дополню статью.
Но при этом никто же не мешает использовать общие интерфейсы, если они действительно хорошо отделяются. Важно чтобы интерфейсы были небольшими, тогда проблем с большим количеством пересечений быть не должно.
Как вы документируете модуль через интерфейсы? Модуль — это же про реализацию. Разные модули могут реализовывать один и тот же интерфейс. У интерфейса немного своя документация. У модуля документация скорее про нюансы реализации.
Основное преимущество что нет лишних зависимостей. Мы не зависим от внешнего интерфейса, который может измениться, или может возникнуть потребность его изменить для других модулей.
В итоге код получается немного проще.
Главное приемущество микросервисов - это независимый деплой, что позволяет нескольким командам работать над разными частями системы не мешая друг другу и применение разных языков программирования. Масштабировать нагрузку можно и в монолите просто повышая количество инстансов. Разделять зону ответственности можно внутри одного кода. Просто разбивая код на модули и классы. Тут микросервисная архитектура ни причем. Какой размер команды и сколько команд занимается поддержкой этой системы?
Кажется монолитная архитектура тут подошла бы лучше, остается больше пространства для маневра и поскольку система молодая, не совсем очевидно что такое разделение правильное, всегда можно потом разбить её на микросервисы когда станет понятней где проходят границы разных частей системы.
Челябинск куда-то потерялся, в середине статьи (
Нет. ZipCodeProvider может быть только в доменном сервисе и лучше в виде интерфейса.
А в чем проблема? Если код написан хорошим программистом, то он читается легко и легко поддерживается.
Если в проекте сложно разобраться, то это значит что программист оказался все таки не так хорош, и не смог написать код в терминах бизнеса, выделить слой прикладной области, выбрал слишком сложную архитектуру и т.д.
Конечно бывают понятные примеры, когда можно использовать наследование, но это часто не так. Например, стоит ли делать родительский класс для репозиториев сущностей из базы данных? А если у дочернему классу не нужны методы родителя? Скорее всего нет.
Если я начну все это расписывать, то ещё одна книга получится. Если вам это правда интересно, прочтите книгу.
Насчет стройки и недосыпа, автор в книге же четко написал
Т.е. он пишет про сложность связанную со структурой IT системы.
Проще, значит разработчику легче работать с этим кодов в будущем, легче его понять, меньше и быстрее переделывать и меньше ошибок возникнет в процессе использования модулей. Автор приводит много примеров разных ситуаций когда можно сделать проще.
Простой интерфейс и реализация — это не бред. Сам часто встречаю в пулл реквестах слишком сложный интерфейс, когда например передают лишние данные в метод. Или приходится всегда вызывать несколько методов по очереди у одного объекта, хотя можно было сделать только один.
С реализацией тоже самое. Например, бывает иногда добавляют проверки, которые никогда не сработают. И зачем тогда они нужны, в них придется больше вникать при попытке понять реализацию и возникнет больше вопросов, почему это здесь.
На самом деле да, нужно просто писать проще. Очень банально, но этого и не хватает для хорошего дизайна. А уже как писать проще, об этом книга.
1) В концовке я написал, что он подходит для больших проектов говоря об этом в контексте использования интерфейсов, поэтому я указал, что а не написал, что он точно является подходящим.
2) Я старался показать именно сильные стороны, показывая разницу с самым распространенным способом работы с интерфейсами в популярных языках как Java, C++, PHP. Но видимо да, нужно было привести примеры с других языков, чтобы было понятнее.
Видимо, нужно писать подробнее, раскрывая больше мыслей. Чтобы не было таких недопониманий и негативных реакций. Это моя первая статья на хабре.
Нет. Почему вы так думаете?
Но при этом никто же не мешает использовать общие интерфейсы, если они действительно хорошо отделяются. Важно чтобы интерфейсы были небольшими, тогда проблем с большим количеством пересечений быть не должно.
Как вы документируете модуль через интерфейсы? Модуль — это же про реализацию. Разные модули могут реализовывать один и тот же интерфейс. У интерфейса немного своя документация. У модуля документация скорее про нюансы реализации.
В итоге код получается немного проще.