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.
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.
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.