3

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:

  1. 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?

  2. I also read it's most indicated in complex enterprises. Will would it be effective and have practical advantages on such a simple application?

  3. 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 database

    Would 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?

Improve this question
3
  • 1
    The canonical paper on layered architecture (what you call "onion architecture") is Dijkstra's "Structure of the T.H.E. Multiprogramming System". Read and digest it THOROUGHLY. The most important point is that it made development of the whole system manageable.
    – John R. Strohm
    May 26, 2016 at 20:21
  • Hm. John, are you aware of the onion architecture style of Jeff Palermo? think the way OP structured the layers is just fine, the only thing I would add is some interfaces of L3 and L5 in the domain layer. That way, you will achieve true onion architecture, because the application layer can depend on the interfaces, which are in the inner layer, instead of depending on something that lies in a outer layer.
    – Don Ho
    May 27, 2016 at 4:07
  • 1
    @donat3llo: The fundamental concept of layered architectures is that each layer communicates ONLY with the layers immediately above and immediately below. Layers are NOT skipped. The way he described it, he has the source database talking directly with the output database, and NOT with the application code.
    – John R. Strohm
    May 27, 2016 at 16:54

2 Answers 2

Reset to default
5

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:

  1. Typically nowadays server applications have complex business logic, but there's no reason why the pattern should not apply to any other type application

  2. There are always benefits to separating core functionality from interfaces to other systems

  3. 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.)

Improve this answer
1

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.

Improve this answer
2
  • I think I got it. Now let's say the source database implements a sphere with the radius and output database does it with the diameter. I'll have 'Input DB Sphere' and 'Output DB sphere' objects on Layer 1. Then I'll have to create a third 'Common Sphere' object on the Layer 2, and the translators will convert between them. But this way I will need more memory to store the common object just for translating. Would be bad if my application (Layer 3) manipulates a single translator in Layer 2?
    – rbasniak
    May 26, 2016 at 20:45
  • 1
    @RBasniak: It depends on what the various layers need. SOME overhead may be unavoidable, but careful design minimizes it. The object of the exercise is to be able to yank out a whole layer, or a component in a given layer, and replace it with something different, and NOT have to change the layers above or below. I'M SERIOUS ABOUT THIS: Read Dijkstra's paper if you haven't already.
    – John R. Strohm
    May 27, 2016 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.