I recently started working on a new project where the team was considering use onion architecture, which I was not very familiar with, so I started reading about it.
The application is a simple 3D format converter. It will read a sql database, convert the data and then write the new format in another MySql database. The first database is very complex itself, but I don’t think it’s mather. The application concept is very simple: read from A, convert, write to B. I won’t have any services or special infrastructure for it.
It will be a desktop application.
Based on these facts, I ask:
-
Everything I read about onion is related to web applications. Is there any special reason why it’s not very popular in a desktop application?
-
I also read it’s most indicated in complex enterprises. Will would it be effective and have practical advantages on such a simple application?
-
If we go for the onion path, what would be in the domain layer? Please fell free to comment the following layers:
L1) Source Layer: will represent the data in the source database
L2) Output Layer: will represent the data in the output database
L3) Database Reader Layer: will be responsible for reading source database and populate Layer 1
L4) Converter Layer: will be an adapter that will receive Layer 1 and populate Layer 2 with the converted data
L5) Database Writer Layer: will write the Layer 2 to databaseWould layers 1 and 2 be the my domain layer?
Would layers 3 and 5 be infrastructure?
And layer 4 would be an application or domain service?
3
I’m not so sure that the onion architecture makes much sense in this case.
What you can keep from the onion architecture is the principle that your application core (the translators) should be decoupled from the data access. But overall your requirement is much more like a pipeline.
read -> transform -> write
Now, read and write are impure (difficult to test). Transform could be pure (easy to test) if it does not call write directly. So if you decouple by having the core of your app (transform) return the data to be written, or publish to a queue/observable/bus, then you’ve effectively isolated your core and made it testable. This is the principle of the onion architecture.
About your questions:
-
Typically nowadays server applications have complex business logic, but there’s no reason why the pattern should not apply to any other type application
-
There are always benefits to separating core functionality from interfaces to other systems
-
The domain layer would be the business entities that your DBs ultimately are meant to represent
Whether or not you choose to have a “common” object type, and 2 object types that more closely resemble the representation in your database, in my opinion, is a possibility but not a strict requirement; it just depends on the type of data. You could use your relational model as domain model, and convert to the denormalized model. (I see many applications that duplicate identical objects across layers, ending up with lots of representations for the same data; this is not a good design IMO.)
Your Input Database and your Output Database are each at Layer 1.
Layer 2 will contain two Translators, one for each Database at Layer 1, that translates between the particular database objects and a “common” (or “universal”) object type.
Layer 3, your “application”, manipulates the common objects.
You could view this as a pipeline bent into a “U” shape.
2