0

In Onion Architecture, business logic lives in an inner layer. So it can be referenced by outer layers like the UI, in my case a Web App.

Now I want to create a small companion app that users can install on their phones or computers. Naturally, I'll need a few bits from the business logic, so I'd have to reference the inner circle in my companion app. This would also mean that my whole inner layer will be installed on my users devices Even only a small part of that layer is really used. I have some concerns with that approach:

  1. Some business logic (not used in the companion app) is "secret". Or at least I don't want to expose it like that on a silver plate.
  2. The companion app should be as lightweight as possible. Why deliver code that won't be executed anyway?

I thought about splitting the inner layer into two assemblies. One containing only the stuff needed in the companion app and the other with the rest. I think technically that would work, but it feels wrong because currently there is one clear place for business logic and in future there would be two. And where does it end? What if I had another app, which needs logic from the companion-app-specific assembly?

Sandro
  • 2,998
  • 2
  • 25
  • 51

1 Answers1

0

This would also mean that my whole inner layer will be installed on my users devices Even only a small part of that layer is really used.

Business logic should not be shipped as part of UI. Rather, it should be packed as a set of APIs inside a secured space of yours which makes it much easier to manage restrictions you mentioned.

This way, for example, companion app access a small set of APIs you have defined.

Also, size of code being delivered becomes no issue since you only deliver UI.

Dharman
  • 30,962
  • 25
  • 85
  • 135
desertech
  • 911
  • 3
  • 7
  • That is exactly what I intended by splitting the inner layer into two assemblies. But that creates a new inner layer everytime and it gets messy and impossible. – Sandro Jan 30 '21 at 00:08
  • I cannot see why you make a link between APIs and number of assemblies. Having a set of APIs on server side makes it much easier to ship multiple kinds of UI apps, each of which using **desired** APIs. If you decide, for example, to have a single solution of APIs, you may choose to divide it into as many assemblies as you want, but this is only internal details. The important thing is having multiple endpoints serving all UI apps. – desertech Jan 30 '21 at 09:39
  • If you think of API's like Webservice, then yes. But let's say the app needs a fundamental method to calculate something. This method is placed in the most inner onion layer (Core) because it's business logic. To use said method I create a Web API method, so it can be called from everywhere with HTTP capabilities, without exposing how the calculation really works. The companion app needs a few entities to work. But they also live in the Core. So, when I reference the Core in the app project it will expose also said method because they live in the same assembly. – Sandro Jan 30 '21 at 18:33