It’s not a book, but this is an excellent article on how to structure software in OTP: https://ferd.ca/the-zen-of-erlang.html

Speaking of onion architecture, Scott Wlaschin has a lot of content on the web about DDD from a functional point of view, although he uses F# https://fsharpforfunandprofit.com/ddd/ You’ll also find lots of videos of his talks, and a book: https://pragprog.com/book/swdddf/domain-modeling-made-functional

Note that all of it won’t be applicable to Elixir (static typing, etc.).

On that point, I heartily recommend Greg Young’s talk on The Art of Destroying Software:

https://vimeo.com/108441214

But this describes mainly the syntax and how to perform specific tasks.
I want to know how to plan my software from beginning to end, for longevity, renewability and best pratices for the architecture itself.

In HTML there is the header, then body, then footer etc. Strict that. Simple. (I know, bad example)

Are there any best pratices like this for other applications, like client-server software?
Clearer what i want to know? English is not my main language, sadly…

It looks like you are (rightfully then) asking about architecture, which is merely affected by your choice of programming language. Your architecture should certainly not be depending on phoenix or ecto or whatever framework. Those are implementation details, they should not dictate how you build stuff.

If this sounds like what you’re after, I would suggest reading more about an architecture called with many names: Ports and Adapters / Clean Architecture / Onion Architecture.

There are others but this is certainly one you should check

I just gave a talk along similar lines at ElixirConf: https://www.youtube.com/watch?v=Ue--hvFzr0o.

It covers many things like creating a public (code-level) API and several internal APIs, in an effort to keep your application structured and easy to change down the road. It also covers how to test complex applications, and how to isolate Ecto to the areas of the app that it’s good at.

Hopefully this helps.