page 42

page.txt

@@ -0,0 +1 @@
+42

summary.txt

@@ -0,0 +1,28 @@
+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.