summary.txt

1. Собирайте вместе все, что изменяется по одной и той же причине, и разделяйте все, что изменяется по разным причинам.
2. Достаточно небольшой и не меньше этого.
3. Чем меньше сервис, тем больше проявляются все преимущества и недостатки микросервисной архитектуры. Чем меньше делается
сервис, тем больше становятся его преимущества в смысле взаимозависимости.
4. Нужно стандартизированное API между микросервисами, чтобы уменьшить связность между ними.
5. Каждый микросервис должен быть написан на своей более ему подходящей технологии, исходя из требований производительности.
6. Плюсом служит, то что в определенный сервис можно подоткнуть новую технологию и проверить её в действии,
что не сделать с монолитной архитектурой.
7. В микросервисной архитектуре при отказе одного сервиса, работа системы не должна оставиться, как это происходит в монолитной 
архитектуре.
8. В больших монолитных сервисах расширять приходится все сразу.
9. Для реализации внесения изменений в одну строку монолитного приложения, состоящего из миллионов строк кода, требуется, чтобы было развернуто все приложение.
10. Отделая команда на каждый сервис - продуктивно!
11. Сервис должен состоятб из нескольких сотен строк кода не больше (я так понимаю не больше 500 - 700).
Тогда избавиться от него гораздо легче, и переработать тоже.
12. Сервис-ориентированная архитектура (Service-oriented Architecture (SOA)) представляет собой подход в проектировании, при котором несколько сервисов работают совместно для предоставления некоего конечного набора возможностей.
Здесь обычно понимается полностью отдельный процесс операционной системы. Связь между такими сервисами осуществляется через сетевые вызовы,
а не через вызовы методов в границах процесса.
13. Архитекторам нужно избавиться от мысли о создании совершенного конечного продукта, а вместо этого сфокусироваться на
содействии созданию программной структуры, в которой могут появляться подходящие системы, способные расти по мере более глубокого осмысления стоящих
перед нами задач.
14. Поскольку программами кто-то пользуется, мы должны реагировать на процесс их использования и вносить в них изменения.
15. Всего, что может произойти, предвидеть невозможно, и поэтому вместо планирования готовности к любым неожиданностям нужно составлять такой план, который позволит вносить изменения, и избавляться от чрезмерного желания определить окончательный вид каждого компонента.
16. В качестве архитекторов нам нужно больше заботиться не о том, что происходит внутри зоны, а о том,
что происходит между зонами. 
17. Волноваться за все, что происходит между блоками, и снисходительно относиться ко всему, что делается внутри них.
18. Приложения надо составлять исходя из требования бизнеса, из принципов бизнеса, которых должно быть не более 10.
19.