I have been reading quite a lot about design and architecture in Elixir and overall FP. My latest incursions took to me the Onion Architecture and the Functional Core / Imperative shell:
Only to find out that there is no real consensus among the community. From what I understand the community overall likes decoupling but it is still finding and architecture that works.
Question
That post is however quite old, as well as the resources they link to ( some of them are from 2015 ). I was wondering if there are any books, courses and material over all where I can learn software design and architecture in Elixir ( using the Actor model perhaps together with a layered architecture ) that donât use frameworks, like Phoenix. I am looking for something more ⊠agnostic. mainly because I see Phoenix is used mainly for webapps.
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).
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.
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.
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.
Even in OOP the best way to determine abstractions (use of design patterns) was to look at the messages between objects. Regardless of if the objects were calling methods on each other and it wasnât at all the same as a BEAM process messaging - the way to figure out how to decouple and configure dependencies was too look at the messages and the contracts between components.
The difference lies with imperative OOP-style vs actor model and how first-class messaging is. To achieve architectural goals by inverting dependencies and implement decoupled systems with imperative-OOP requires (in my opinion) more overhead and complexity. So much so that there are entire books about the design patterns! (I really like Sandi Metzâs books on OOP because thereâs less emphasis on the design patterns and more on the messages). Regardless itâs more straightforward in our actor model world. Maybe messaging contracts seem scarier because we donât have a handy book of conventions to use?
The part of Domain Modeling Made Functional I really liked was his description of different messaging contracts between contexts. Scott broke it down into three different types (paraphrasing):
Shared Kernel: A shared module that separate bounded contexts or pieces of the system depend on. A given change requires coordination between both contexts. This entails high coupling and costs in exchange for properties like compliance and preventing breaking changes made by one team.
Consumer Driven: The downstream consumer of messages dictates how the producer must behave. If the consumer wants a change, the producer must conform to the new contract.
Producer Driven: The producer of the message controls how the consumer must behave. The consumer must comply to changes made by the producer or break.
A big shared kernel we have in the ecosystem are Ecto Changesets. Phoenix uses Ecto Changeset for Phoenix HTML. Thereâs a trade-off of dependencies but we get benefits of surfacing errors from changesets and reducing a lot of work. The mutual dependency is probably fine since Ecto is a well-established and stable open source project, but itâs there none-the-less.
So what the Elixir community uses (mocks / behaviours / messaging contracts) are in the same category as the gang of four pizazz but simpler because the actor model puts messages first class.
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.
We have an Elixir Foundation video series, with 10 episodes out and more on its way, we use elixirâs plug for the web layer, show you how to create your own project from scratch.
You can see the full table of contents here 
