The best architecture book I’ve ever read in my 25 year career is Designing for Scalability with Erlang/OTP but as the title implies, the examples are all in Erlang. The good news is it all applies in Elixir since we share OTP and BEAM, but you’ll have to invest the time to at least be able to read basic Erlang (which isn’t hard).

If I understand what you are saying, you seem to be unclear why so much “reusability” seems to revolve around Behaviors instead of functions.

Read Chapter 3. Behaviors on Google’s sample.

Processes interact through messages, not function invocations therefore process skeletons are implemented as Behaviors.

• OTP design principles
• Learn You Some Erlang: What is OTP
• [style] Parametrising generic functionality: behaviours vs protocols
• Why is Access a behaviour instead of a Protocol? When to use a Protocol instead of a Behaviour?
• Difference between protocol & behaviour in elixir
• Mox and Protocols?

Very good points overall @MrDoops, but I’d like to offer one clarification.

phoenix_html defines a protocol called FormData and implements it for Ecto.Changeset to minimize that coupling. I don’t believe F# has protocols, so it wasn’t an option in the book. Elixir copied that idea from Clojure.

I suspect that you are now venturing into an area where focusing on Elixir-specific resources is going to isolate you from potentially useful information. Then there is the other consideration that these information sources will tend to require more work on your part to transfer value into the Elixir realm.

Given that you have already had some exposure to Scott Wlaschin, [Functional Programming] Domain Modeling Made Functional (Pragprog) (F#) may be worthwhile even if it is in F# rather than Elixir (one discussion that precipitated from it). Chapter 3 is actually called “Functional Architecture”.

Then of course there is [Erlang] Designing for Scalability with Erlang/OTP (O'Reilly) (ebooks.com, Google). While there are no “prescriptive architectures” being discussed as such, it does give you insights on the principles that the BEAM design was based on which in turn builds a better understanding which “architectural approaches” compliment or fight it.

Strangely enough sources like Principles of Service Design have some interesting tidbits (i.e. not everything is relevant) simply because it moves beyond dogmatic object thinking. E.g. Service Autonomy as aspect of a bounded context.

And a lot of the material you see today still draws from Pattern-Oriented Software Architecture, Volume 1, A System of Patterns, Patterns of Enterprise Application Architecture and Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.

The issue is that advice is now going to be much less focused and prescriptive because of an increasingly significant “it depends” factor. For example where an Elixir solution is deployed is going to exert different architectural and design pressures.

I take it you bought the course? What were your impressions?

Interesting, which patterns do they talk about?

@peerreynders My greatest fear is not being able to transport what I learn into Elixir. I guess I could try Domain modeling made functional, since I have watched quite a number of conferences from Scott and I don’t think F# is too different from Elixir.

If I had to pin point it, I would say that my greatest issue right now is not understanding why Elixir is so focused on Mocks when it can use Functional DI (which I have been using in JS for years now) and I am still not clear on how this approach would affect my work.

At the end of the day I really want a project easy to change/modify and understand. I know there isn’t a silver bullet but I guess I am hoping for some guideline.

Thanks for the resources!