anthonator
Discussion: Onion Architecture
I’m curious to hear people’s opinions on implementing the Onion Architecture in an Elixir application.
Jeffrey Palermo, the originator of the Onion Architecture, states that it is “unashamedly biased toward object-oriented programming, and it puts objects before all others”. However, there has been some discussion on implementing the Onion Architecture in Functional Programming.
The diagram depicts the Onion Architecture. The main premise is that it controls coupling. The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core. In other words, all coupling is toward the center. This architecture is unashamedly biased toward object-oriented programming, and it puts objects before all others.
Has anybody in the Elixir community implemented the Onion Architecture in Elixir or another functional language? Has anybody implemented the Onion Architecture in an OOP language? If you have, what are your thoughts on implementing this architecture?
Do you think this architecture could be useful to the Elixir community? Is using this architecture a bad idea? A good idea? A waste of time? Do Elixir apps tend to exhibit this architecture anyway?
I’m looking forward to hearing people’s thoughts!
Most Liked
peerreynders
However, I am intrigued by the clear separation between domain, application, and infrastructure code.
I’m not against being organized (i.e. observing separation of concerns) - in fact most of the success stories are probably based on the fact that projects went from not managing boundaries and dependencies appropriately to starting to having to think about them - but that doesn’t give the onion architecture “special powers”.
Most apps that I encounter in the wild are “database first” and place the infrastructure layer in the middle.
To certain degree that is simply an matter of perspective - and typically there are multiple perspectives. The onion architecture’s primary claim to fame is the direction of the interfaces - something that can’t even be discerned in the primary graphic. The domain logic gets to dictate the interfaces and types and the infrastructure has to implement everything based on those constraints.
So for example in Java-land that would mean that none of the classes in Java.sql would be allowed in the domain code, even something as convenient as ResultSet because that would ultimately couple the domain logic with the notion of a relational database. From the perspective of the Dependency Inversion Principle this has always been the right thing to do:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
By extension Ecto.Changeset has no business appearing anywhere in your domain logic because Ecto is ultimately only part of your infrastructure - not your domain. So according to DDD you would have to build a repository around Ecto’s repo and transform all inbound and outbound data to basic and domain datatypes - no leaking of changesets and schemas allowed.
it doesn’t seem obvious to a good number of smart people I’ve worked with.
Loose coupling adds effort upfront. So a lot of those “smart people” will accept tight coupling either of their own accord (laziness) or because of pressure by management to produce something (we need this yesterday).
Crowdhailer
This might be a slightly controversial point but I don’t think Elixir code needs to be very different from OO code. A user struct is not very different from an immutable user object. The domain core being functionally pure is I link a good idea because it makes units very easy to test.
By the time you step out to application services and infrastructure, your code will no longer be pure. However at this level a Elixir program will probably be coordinating multiple process and they encapsulate state so again many of the OO lessons are still relevant.
So in summary I think that the onion architecture in Elixir is a good idea.
StefanHoutzager
I did not dive into the onion thing. My time is limited, and I just read that tip of mr. Kunikow: [Functional Programming] Domain Modeling Made Functional (Pragprog) (F#). The writer of that book is also a nice humoristic and clear presenter. I can recommend
https://www.youtube.com/watch?v=AG3KuqDbmhM on the subject of a comparison of oo and fp dependency injection (it comes a bit later in the presentation).
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security










