emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. – Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
3.48K subscribers
119 photos
15 videos
22 files
1.14K links
Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, Extreme Programming, SDLC, Agile, etc.

Chat: https://news.1rj.ru/str/emacsway_chat

Persistence: https://dckms.github.io/system-architecture/
Download Telegram
Одной из частых проблем, с которой сталкиваются разработчики ПО на практике, является разрешение противоречия между обобщением кода (функциональности) и владением интерфейсом.

Когда некая функциональность встречается в коде два и более раз, возникает желание устранить дубликаты и обобщить переиспользуемый код. В качестве примера можно привести главу "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
Возможно, эта ссылка кому-нибудь окажется полезной: https://martinfowler.com/bliki/DecreedStories.html

Не самое исчерпывающее разъяснение, но зато кратко, метко и авторитетно.

#Agile
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Бегло просмотрел книгу: "Team Topologies: Organizing Business and Technology Teams for Fast Flow" by Matthew Skelton https://www.goodreads.com/book/show/44135420-team-topologies , и оказался впечатлен. Книга хорошо раскрывает тему, которую я рассматривал…
Alexander Polomodov (Director of digital ecosystem development department at Tinkoff), опубликовал сегодня пост с обзором книги "Team Topologies: Organizing Business and Technology Teams for Fast Flow" by Matthew Skelton, Manuel Pais:

"Обзор книги “Топологии команд” (“Team Topologies”) — Часть I"
https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0

"Обзор книги “Топологии команд” (“Team Topologies”) — Часть II"
- https://apolomodov.medium.com/review-team-topologies-part-2-2fd21c25f2fd?source=rss-b687aae72973------2

"Обзор книги “Топологии команд” (“Team Topologies”) — Часть III"
- https://apolomodov.medium.com/review-team-topologies-part-3-552f8a010492?source=rss-b687aae72973------2

Еще один обзор этой книги:
- https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/resources/book-notes/team-topologies

#Management #Agile #SoftwareArchitecture
InfoQ: The Software Architects' Newsletter, June 2021
- https://assets.infoq.com/newsletter/architect/en/newsletter_sample/47Architects_NL_June2021.html

AsyncAPI продолжает укреплять свои позиции.

А Nginx опубликовал в свободном доступе Ebook "Designing and Deploying Microservices" - краткий справочный гайд по микросервисам всего на 80 страниц:
- https://www.nginx.com/resources/library/designing-deploying-microservices/

#SoftwareArchitecture #Microservices #DDD #SoftwareDesign