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.
