В Миро удобно, а чтоб быстрее шло - деление на комнаты в zoom.

Еще один неплохой лаконичный материал по распределенным системам, больше напоминающий конспект:
"Distributed systems: for fun and profit" (2013). An introduction to distributed systems.
- http://book.mixu.net/distsys/
Source code:
- https://github.com/mixu/distsysbook

#DistributedSystems #DDD

Превосходная статья по Causal Consistency (Causal Dependencies) доступным языком:
"HighLoad++, Михаил Тюленев (MongoDB): Causal consistency: от теории к практике"
https://habr.com/ru/company/ua-hosting/blog/487638/

[UPDATE]: Есть ещё видео-версия:
- https://youtu.be/UnAprFMX1d4

#DDD #Microservices #DistributedSystems #EIP

Немного о топологии DevOps команд в масштабируемом Agile:

"What Team Structure is Right for DevOps to Flourish?" by Matthew Skelton
https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

"DevOps Topologies"
https://web.devopstopologies.com/

"System Team"
https://www.scaledagileframework.com/system-team/

#Management #SoftwareArchitecture #Agile #DevOps

Превосходный справочно-информационный ресурс по вопросам CRDT от Martin Kleppmann:
- https://crdt.tech/

Source Code:
- https://github.com/ept/crdt-website

Кстати, тем, кто читает его книгу "Designing Data-Intensive Applications", было бы интересно знать, что у него есть проект на GitHub, где он актуализирует все ссылки:
- https://github.com/ept/ddia-references/commit/917f91fbcfe421d0cb2e309625aaf058d910e679

#DistributedSystems #DDD #Microservices #CRDT

Список литературы по аналитике:
- https://www.volere.org/resources/books/
- https://systems.education/books

Список инструментов для управления требованиями:
- https://www.volere.org/tools/
- https://www.volere.org/requirements-tools/

Шаблоны спецификаций требований:
- https://www.volere.org/templates/

#SoftwareArchitecture #Analysis #SoftwareRequirements

Alexander Polomodov (Director of digital ecosystem development department at Tinkoff), опубликовал на днях пост:

"Современные подходы к разработке программного обеспечения"

Интересен список литературы в конце статьи.

#SoftwareArchitecture #SoftwareDesign

Думаю, что это архитектурное описание вполне можно использовать в качестве примера https://github.com/team7katas/sysopsquad Идея со стикерами нефункциональных требований, так вообще зачетная ;-)

Два интересных расширения Sphinx-doc для трассировки требований:
1) https://sphinxcontrib-needs.readthedocs.io/en/latest/
2) https://0x6d64.github.io/sphinx-traceability-example/

Первое из них позволяет превратить Sphinx-doc в практически полноценную Open Source систему управления проектом, построенную на одних только текстовых файлах.

P.S.: Ранее Sphinx-doc уже упоминался в контексте систем управления знаниями.

#SoftwareArchitecture #Analysis #SoftwareRequirements

"Functional programming in Go with generics"
- https://ani.dev/2021/05/25/functional-programming-in-go-with-generics/

"Why Go Getting Generics Will Not Change Idiomatic Go"
- http://www.jerf.org/iri/post/2955

#FunctionalProgramming #Golang

Визуализатор алгоритмов
- https://www.cs.usfca.edu/~galles/visualization/

Visualizing Algorithms
The best way to understand complex data structures is to see them in action. We've developed interactive animations for a variety of data structures and algorithms. Our visualization tool is written in javanoscript using the HTML5 canvas element, and run in just about any modern browser -- including iOS devices like the iPhone and iPad, and even the web browser in the Kindle! (The frame rate is low enough in the Kindle that the visualizations aren't terribly useful, but the tree-based visualizations -- BSTs and AVL Trees -- seem to work well enough)

#Algorithms

"A pure golang SQL database for database theory research"
- https://github.com/auxten/go-sqldb

#Database #Golang

"Snapshots in Event Sourcing" by Oskar Dudycz
https://www.eventstore.com/blog/snapshots-in-event-sourcing

#DDD #EventSourcing #Microservices #SoftwareDesign #SoftwareArchitecture

Vladimir Khorikov опубликовал статью на актуальную тему "Nulls in Value Objects":
- https://enterprisecraftsmanship.com/posts/nulls-in-value-objects/

Статья разбирает, когда использовать Null-значение, а когда - NullObject-pattern. И какую роль здесь играет Maybe monad.

#DDD #SoftwareDesign #Microservices

Jimmy Bogard начал начал работать над циклом статей с демонстрационным кодом "Domain-Driven Refactoring"
- https://jimmybogard.com/domain-driven-refactoring-intro/

#DDD #SoftwareDesign

По материалам доклада моего коллеги на GopherCon Russia 2020, была написана статья "Как писать кодогенераторы в Go"
- https://habr.com/ru/company/omprussia/blog/558690/

#Golang

M.Fowler решил разъяснить, чем отличается integration test от sociable unit test, в новой публикации "On the Diverse And Fantastical Shapes of Testing"
- https://martinfowler.com/articles/2021-test-shapes.html

#Testing

Хоть и не ново, но вдруг кто не знал - цикл статей Gregor Hohpe "Thinking Like An Architect":
- https://architectelevator.com/architecture/famous-architects-sketch/

#SoftSkills #Career

Одной из частых проблем, с которой сталкиваются разработчики ПО на практике, является разрешение противоречия между обобщением кода (функциональности) и владением интерфейсом.

Когда некая функциональность встречается в коде два и более раз, возникает желание устранить дубликаты и обобщить переиспользуемый код. В качестве примера можно привести главу "Layer Supertype" книги "Patterns of Enterprise Application Architecture" by Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford.

Проблема в том, что у интерфейса не может быть два и более владельца. У клиентов возникает зависимость от сторонней библиотеки, которая будет изменяться в другое время, с другой частотой и по другим причинам. Хорошо, если этой библиотекой владеет та же самая команда, которая её и использует. А если нет? А если она используется слоем самого высокого уровня политики - доменным слоем, как в приведенном выше примере, который, кстати, предлагает такое решение:

📝 "You can place the interface in the client's package (as in the sketch) or in a third package (Figure 18.1). If there's only one client for the implementation, or all the clients are in the same package, then you might as well put the interface in with the client. A good way of thinking about this is that the developers of the client package are responsible for defining the interface. Essentially the client package indicates that it will work with any other package that implements the interface it defines. If you have multiple client packages, a third interface package is better. It's also better if you want to show that the interface definition isn't the responsibility of the client package developers. This would be the case if the developers of the implementation were responsible for it."

И все-таки, можно ли избежать образования зависимости доменного слоя приложения от сторонней библиотеки?

Для выравнивания интерфейсов служит паттерн Adapter. По хорошему, приложение должно локализовать изменения используемого стороннего интерфейса посредством адаптера, интерфейсом которого оно владеет. На практике вряд-ли кто-то будет этим заниматься, и код обрастет зависимостями.

Решением могла бы быть генерация этого самого адаптера сторонней библиотекой. В момент генерации, владение интерфейсом переходит от сторонней библиотеки к её клиенту. Таким образом произошло бы отделение обобщенной функциональности от интерфейса, и противоречие было бы разрешено. К такому же выводу приходит и Sam Newman, при решении аналогичной проблемы:

📝 "If your use of shared code ever leaks outside your service boundary, you have introduced a potential form of coupling. Using common code like logging libraries is fine, as they are internal concepts that are invisible to the outside world. RealEstate.com.au makes use of a tailored service template to help bootstrap new service creation. Rather than make this code shared, the company copies it for every new service to ensure that coupling doesn’t leak in."
-- "Building Microservices. Designing Fine-Grained Systems” 2nd edition by Sam Newman

#SoftwareDesign #DIP #DI