What do they actually mean when they say "Phoenix is not your application"?

peerreynders · January 19, 2018, 3:01pm

Topics:

Points

The idea isn’t actually new - but it seems that web development (RoR in particular) needed to rediscover the concept - e.g. Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin (and it wasn’t new back then either).
Design the application code in such a way that all its capabilities can be exposed via different user interfaces, e.g.:
command line interface
native desktop user interface (not something like React Native but more like Swift and not necessarily via a remote server but more like a local application).
web ui (Phoenix + browser frontend)

i.e. decouple the application logic entirely from the nature of the UI (the “mode of delivery” for the application’s capabilities).

Dave Thomas actually pushes the idea even further to “Your Database is not Your Application”
Don’t start by defining your DB tables - that is just your “data-at-rest”. Make informed design decisions based on your “data-in-motion” by designing your essential data transformations (based on your problem domain) first.
Pushed to the extreme this also means that your domain logic should be “persistence technology agnostic”.
Ultimately this goes back to the old idea of a “Layered Architecture”.
However this time around that “layered architecture” isn’t designed “bottom-up” (DB-first) nor “top-down” (UI-first) but “inside-out” (domain-capabilities-first). Conceptually the middle layer (domain-layer) defines all the “interfaces” that the lower layer (persistence-layer) and the upper layer (UI-layer) have to implement.
So the lower layer has to implement the interfaces so that the middle layer can retrieve the necessary data and save and update the necessary data. The upper layer has to implement interfaces to gain access to the middle layers capabilities.