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
Эмуляция Eventstore на PostgreSQL:
- http://docs.eventide-project.org/user-guide/message-db/

Может оказаться полезным для тех, кто работает над сертифицированными решениями.
Есть хорошие адаптеры на Ruby в виде отдельных библиотек.

#Database #PostgreSQL
Обширный список словесных нападок, разбитый на категории и сопровождаемый примерами http://www.vandruff.com/art_converse.html

Как говорится, предупрежден - значит вооружен.

#Management #Career
"When to use the microservice architecture: part 5 - the monolithic architecture and rapid, frequent, reliable and sustainable software delivery" by Chris Richardson
http://chrisrichardson.net/post/microservices/2021/02/14/why-microservices-part-5-monolith.html

#Microservices
Хочу обратить внимание на одну, на мой взгляд, недооцененную сообществом книгу по алгоритмам.

“Introduction to the Design and Analysis of Algorithms” 3d edition by A.Levitin

Принципиальной иной взгляд на классификацию алгортимов, хотя автор утверждает, что этот взгляд уже имел место и до него, просто не очень распространен.

Есть качественный перевод на Русский.

Наверное, это самая легкая книга по алгоритмам из всех, что я встречал (по крайней мере, среди иностранных). Сбалансированное присутствие математики. Читается на одном дыхании. Решил глянуть о чем она, и не заметил, как за день буквально проглотил 75 страниц. Отличное учебное пособие для новичков.

#Algorithms
Один из наиболее частых вопросов - есть ли жизнь без Outbox pattern?

Да, есть, и Outbox нужен далеко не всегда.

В руководстве Microsoft https://docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/subscribe-events#designing-atomicity-and-resiliency-when-publishing-to-the-event-bus
и в каталоге Chris Richardson
https://microservices.io/patterns/data/transactional-outbox.html
в качестве альтернативы Outbox приводится Event Sourcing, иногда реализуемый в виде Front-Door Queue
https://github.com/obsidiandynamics/goharvest/wiki/Comparison-of-messaging-patterns#front-door-queue . При этом, становится важной поддержка идемпотентности.

В EIP ("Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf) есть весьма познавательная, и, к сожалению, малоцитируемая глава "Transactional Client", которая рассматривает вопрос "Transactional Consumer" vs "Transactional Sender".

📝 "Both a sender and a receiver can be transactional. With a sender, the message isn’t “really” added to the channel until the sender commits the transaction. With a receiver, the message isn’t “really” removed from the channel until the receiver commits the transaction. A sender that uses explicit transactions can be used with a receiver that uses implicit transactions, and vise versa. A single channel might have a combination of implicitly and explicitly transactional senders; it could also have a combination of receivers.

With a transactional receiver, an application can receive a message without actually removing the message from the queue. At this point, if the application crashed, when it recovered, the message would still be on the queue; the message would not be lost. Having received the message, the application can then process it. Once the application is finished with the message and is certain it wants to consume it, the application commits the transaction, which (if successful) removes the message from the channel. At this point, if the application crashed, when it recovered, the message would no longer be on the channel, so the application had better truly be finished with the message.

How does controlling a messaging system’s transactions externally help an application coordinate several tasks? Here’s what the application would do in the scenarios described above:
"
- "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf

Этот же вопрос, но немного с другой терминологией, "Transactional Client" vs "Transactional Actor", рассматривается в RMPwtAM ("Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka" by Vaughn Vernon).

Те, кто пишут на Golang, могут использовать коробочные решения Outbox:
- https://github.com/ThreeDotsLabs/watermill/tree/master/_examples/real-world-examples/transactional-events
- https://github.com/obsidiandynamics/goharvest
- https://github.com/wework/grabbit (поддерживает Saga)
- https://github.com/omaskery/outboxen
- https://github.com/omaskery/outboxen-gorm
- https://github.com/QuangTung97/eventx
- https://github.com/nilorg/outbox

- https://github.com/topics/transactional-outbox?l=go
- https://github.com/topics/outbox?l=go
- https://github.com/topics/outbox-pattern?l=go
- https://github.com/topics/transactional-outbox-pattern?l=go

Watermill интересен тем, что данные в таблицах неизменяемы, т.е. записи ложатся компактно и постранично на диск, и могут быть применены решения для time-series data (timescaledb, pg_partman/pg_pathman...).

#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Один из наиболее частых вопросов - есть ли жизнь без Outbox pattern? Да, есть, и Outbox нужен далеко не всегда. В руководстве Microsoft https://docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/subscribe…
С поддержкой Generics в Golang открываются новые возможности в использовании приемов функционального программирования.

См. главу "Monadic Error Handling":
https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/

Это вынуждает по новому взглянуть на широко известный среди функциональщиков Railway Oriented Programming:
- https://fsharpforfunandprofit.com/rop/
- https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

Перевод на русский статьи "Railway Oriented Programming":
- https://habr.com/ru/post/339606/

Еще одна ссылка, на эту тему:
- https://medium.com/@naveenkumarmuguda/railway-oriented-programming-a-powerful-functional-programming-pattern-ab454e467f31

А здесь, на слайдах, показана трансформация UseCase of Robert Martin в Railway Oriented Programming:
- https://github.com/swlaschin/RailwayOrientedProgramming/blob/master/Railway_Oriented_Programming_Slideshare.pdf
- https://github.com/swlaschin/RailwayOrientedProgramming/blob/master/Railway_Oriented_Programming.pptx
- https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html#use-cases

Кстати, это является и ответом на вопрос, есть ли жизнь без синхронных Domain Events:

📝 "In an object-oriented design, it is common to have domain events raised internally within a bounded context. In that approach, a workflow object raises an OrderPlaced event, and then a handler listens for that and sends the order acknowledgement, and another handler generates a BillableOrderPlaced event, and so on.
<...>
In a functional design, we prefer not to use this approach, because it creates hidden dependencies. Instead, if we need a “listener” for an event, we just append it to the end of workflow...
<...>
This approach is more explicit – there are no global event managers with mutable state – and therefore it is easier to understand and maintain."
- "Domain Modeling Made Functional. Tackle Software Complexity with Domain-Driven Design and F#" by Scott Wlaschin
https://fsharpforfunandprofit.com/books/

Кстати, на github.com по этой теме в топе ребята из @drypython :
- https://github.com/topics/railway-oriented-programming

Одна из библиотек, облегчающих использование Railway Oriented Programming в Python: https://github.com/proofit404/stories

#FunctionalProgramming #DDD #Golang
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
С поддержкой Generics в Golang открываются новые возможности в использовании приемов функционального программирования. См. главу "Monadic Error Handling": https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/ Это вынуждает по новому взглянуть…
Кстати, агрегаты вот этого DDD/Golang reference application https://github.com/AntonStoeckl/go-iddd выполнены в функциональной парадигме. Об этом автор пишет в сопроводительных статьях к приложению.

📝 "My Aggregate used to be implemented in OOP style with inline state in the past. My little project is event-sourced and I decided a while ago that I want to implement a functional core. Event-Sourcing is quite functional by nature, so I decided that my Aggregate will only consist of functions! My first functional version did not even have a state object. It simply projected all necessary properties into local variables. Not long ago I introduced a currentState object — which is unexposed — so only visible inside the Domain subpackage customer in which my Aggregate lives."
- "Implementing Domain-Driven Design and Hexagonal Architecture with Go (2). Part 2 — How I implement tactical DDD patterns — the Domain layer" by Anton Stöckl
https://medium.com/@TonyBologni/implementing-domain-driven-design-and-hexagonal-architecture-with-go-2-efd432505554

#DDD #Golang #FunctionalProgramming
Forwarded from Yuriy Yarosh
По поводу https://news.1rj.ru/str/emacsway_log/377 и функциональщины

Надо понимать что у golang2 пока непонятно как будут обстоять дела с контролируемым развёртыванием хвостовой рекурсии, и будут ли для этого дополнительные примитивы (@tailrec аннотация в случае с JVM языками).

С функциональных примитивов, более продвинутые вещи, типа IO монад и Eval, без этого реализовать не получится.

Eval нужен для стэкобезопасности любого куска кода который он оборачивает - все рекурсивные вызовы внутри не будут приводить к переполнению стэка, но должны тоже возвращать Eval.

IO нужен для ROP'a и весь код обёрнутый внутри автомагически будет работать по ROP'у без дополнительных плясок.

Потому Eval/IO довольно сложно реализованы что в Cats / Scalaz что в Arrow.kt.
Для Arrow пришлось отдельный плагин к компилятору писать (https://github.com/arrow-kt/arrow-meta), ну и для скалы тоже есть для better-monadic-for плагин (https://github.com/oleg-py/better-monadic-for).

Как это будет реализовано в голанге - непонятно, но про модульность плагинов к компилятору точно можно не мечтать.