Software design patterns and reference architectures

Chat / Discussions
, ,
1

I’m doing a bit of research and writing on software design patterns and reference architectures relevant to Elixir applications.

Often it seems the discussion around architecture and design patterns seems to be dominated by the idea that they are irrelevant in the context of functional programming, and while this might be true for the original GoF patterns; I feel there is still a few useful patterns yet to be fully explored in the realm of Elixir.

Top of mind, and highly colored by my background:

  • Flow-Based programming to build robust and scalable data pipelines
  • Event Sourcing for use cases where traceability is highly important

What other patterns could be useful or are you currently using? Would love to hear from other developers what is currently being used in production and with that amount of success.

3 Likes
2

It’s lower-level than the examples you gave, but the OTP Design Principles document should be on your radar.

1 Like
3

I think most of the GoF can be implemented in elixir. In ruby, many of them are made trivial via metaprogramming, the same would be true in elixir. I have used the Strategy pattern, and am currently working on a Bridge pattern. I would recommend posting a github page for submissions on independent libraries, or some way of compiling a collection from the community. Could be really useful. What do people think of this Strategy ?

# start server with default formatter
defmodule Report do
  use GenServer

  def start_link(formatter) do
    GenServer.start_link(__MODULE__, formatter, name: __MODULE__)
  end

  def init(formatter), do: {:ok, formatter}

  def handle_call({:output_report, context}, _from, formatter) do
    formatter.output_report(context)

    {:reply, :ok, formatter}
  end

  def handle_call({:change_format, new_formatter}, _from, _state),
    do: {:reply, :ok, new_formatter}

  # Public APIs
  def output_report(context),
    do: GenServer.call(__MODULE__, {:output_report, context})

  def change_format(formatter),
    do: GenServer.call(__MODULE__, {:change_format, formatter})
end

defmodule Activities do
  def output_report(context) do
    IO.puts("***** #{context.title} *****")

    Enum.each(context.text, &IO.puts/1)
  end
end

{:ok, _} = Report.start_link(Activities)

context = %{
  title: "Monthly Report",
  text: ["Things are going", "really, really well"]
}

# Change the formatter at runtime
Activities.output_report(context)
4

This idea is best backed by a Behaviour (as is any scenario where you are making function calls to modules dynamically).

I’d say it’s one of a few GoF patterns that have a direct analog in pattern-matching functional languages. Most of them can either be elegantly handled with or made redundant by, pattern matching and/or functional programming.

1 Like
5

Exactly, part of what I’m trying to find out is which architectural or design patterns are actually relevant/applicable to elixir. There are a few that can be interesting, so far I’ve spend more time looking at both CQRS and Event Sourcing, the Saga pattern also seems potentially viable.

6

While the question is relevant for sure, I’d think that in FP the very fact that you can use functions as values already opens you a lot of doors. In my own case, even though I am at years of career where people expect me to become an “architect” I feel that it’s much better to simply start a project and let any relevant patterns emerge along the way.

1 Like
7

This might be useful in some situations but doesn’t really replace the need for all patterns, we still have to make decisions of how we architect our code and the application as a whole.

And this might be perfectly okay for smaller applications but when working on a larger scope, see what might emerge, and hoping you don’t have to refactor anything is not necessarily an option.

I think Design patterns and the term “architect” might have unsavory connotations in certain circles just because of how much they have been abused.

1 Like
8

Now that I completely agree with. I was there when the infamous “Java enterprise architects” ran rampant and ripped companies off of millions of dollars so I definitely have some PTSD about it. :smiley:

Yes and no. If you use some well-known Elixir flavour of doing things (like configuring implementations and using dynamic dispatch) from the get go then this allows you to juggle a lot of complexity in the future. All that’s necessary is being a little clever at the start – but not too clever so as to lock yourself into a certain paradigm that might indeed turn out to be ill-advised 300k coding lines later.

I am not disagreeing with you – I am simply adding the nuance that we have it easier in FP. I’ve had to refactor and re-adapt huge Java and Ruby codebases in the past and that’s basically a perfect way to want to commit suicide.

2 Likes
9

That’s an excellent point.

Agreed, and I can relate, and that is the thing I found when looking into Desing patterns in FP or elixir; GoF is pretty redundant and not neat because as you say we have it easier with FP.

2 Likes
10

Indeed. Helps to go back to first principles. Thanks for pointing this out, since a behavior is just dynamic dispatch polymorphism, as “strategies” can be combined, mixed, and matched. Eureka!

2 Likes