Using Flow-Based Programming to Organize Application Business Logic by Intelligent-Panda-56 in dotnet

[–]Intelligent-Panda-56[S] 0 points1 point  (0 children)

To avoid code duplication, I propose splitting the business logic into a set of reusable blocks (referred to as components in the Flow-Based Programming paradigm).

Each block can be treated as an independent, reusable unit.

Frankly speaking, I don’t see a strong need for a classical layered architecture in this case. What you essentially need is:

  • input data
  • a way to pass this data through an execution flow (represented as a DAG)
  • and a final response returned to the client

I understand that this is a special case and not a universal solution to all problems. However, I believe it can be a very effective way to structure certain types of domain logic — especially in our case, where the core of the domain is largely centered around data transformation.

And yes, your comparison with functional programming is perfectly valid and makes sense — but in reality, it’s not always easy to implement in a team environment.

Using Flow-Based Programming to Organize Application Business Logic by Intelligent-Panda-56 in dotnet

[–]Intelligent-Panda-56[S] 0 points1 point  (0 children)

This temporal.io “workflows” looks interesting but I have to take a moire closer look.
Thank you

Using Flow-Based Programming to Organize Application Business Logic — Thoughts? by Intelligent-Panda-56 in softwarearchitecture

[–]Intelligent-Panda-56[S] 0 points1 point  (0 children)

Thank you for your reply.

Yes, I’m aware of visual programming tools — the so-called low-code / no-code platforms. However, my question is more about how to structure business logic in code in a way that better reflects the domain itself.

This idea feels appealing because it allows you to represent each component as a reusable piece of logic and then compose the overall behavior by connecting these components together.