0

I am working on a big modernization of .NET client server app. I am planning to apply "Onion Architecture" as i feel it is matching the modernization approach that future architecture is not yet finalized.

Anybody used Onion Architecture for legacy modernization and your inputs will be helpful.

Rajan R.G
  • 825
  • 1
  • 7
  • 10
  • How big is your application? How many different components it will have (databases, caches, message queues, rest api`s, legacy stuff to connect/integrate...)? – Saša Šijak Dec 10 '13 at 09:01
  • Hard to say that Onion architecture would fit without further details. But keep in mind that any architectural decision must have a business added value. Do not apply this or that for the sake of it, just because you want to give it a try or just because of the buzzword. – MaxSC Dec 10 '13 at 09:04
  • That's the reason i posted in StackOverflow. I am watching the Onion Architecture community for the last 3 years. @SašaŠijak It doesn't have MQs but integration is there. – Rajan R.G Dec 10 '13 at 09:26
  • @RajanR.G Don't get me wrong, I'm a huge Onion architecture fan. I'm just trying to avoid to mislead you as an architecture choice is something really fundamental to which you will be tied till the end of your project. If your application is quite simple, the best choice, IMHO, would be to start simple. This is why advise you on an architectural choice without any more details on your app, is pretty difficult. – MaxSC Dec 10 '13 at 09:53
  • Got it. Nothing wrong. I am just interested to know whether anyone has any success or failure stories on this. – Rajan R.G Dec 10 '13 at 10:24

1 Answers1

0

The core of onion architecture is your business domain. This means you either need to be an expert in the business yourself or have direct access to business expert who can explain business rules to you. If you are modernizing significant part of your application, a part fulfilling at least one cohesive business transaction, then go for the onion architecture. Otherwise onion will not help. Onion architecture provides real loose coupling. For example, in case of e-commerce check out flow - basket, payment, and stock availability may each have own onion (microservice?). Each of these onions can be implemented in different technologies, e.g. basket in MEAN stack, payment on Mainframe, and stock availability in Java. As you can see onion architecture provides decoupling of business logic from technology implementing it. If you need more information on how to effectively use onion architecture, I will refer to books about domain-driven design. InfoQ has s free one for starters, https://www.infoq.com/minibooks/domain-driven-design-quickly Feel free to contact me, if you got any questions. I am a long time practitioner of using onion architecture in conjunction with domain-driven design.

Temian
  • 1
  • 1