Great, thanks for your feedback @kristinalim!
Yes, that’s the point and the mindset. Also, even if we have dependencies between main app and domains or the other way around, most of them will not be circular, unless you count main_app/routes redirect to domain/routes to be a dependency.
API wrapper for APIs of domain-engines
I am so happy to read what you just wrote here. This is the whole point of this thread actually! Do you know why? Because these gems you talk about here, they are for clients of our API, that means, anyone can use them to interact with the OFN API.
But… I think some people will feel this may be too forward looking for OFN (mainly because it is quite a big step), so we may just accept that, for now, we can make domains depend on each others models or services or other things like AMS serializers…
General utilities and behaviour
We can call it ofn-commons Or we can create many smaller/specific gems. Also, we can keep all this in the main app’s /lib folder, from what I understand this is what /lib is for.
Actually, I want to see what exact code we are talking about here, and then we can decide where to put it
Yes, we need to move away from the style of app where all places in the app have access to all other places. We need to create indirection layers (to reduce complexity/chaos), and that is not as fast/simple as accessing the data we need in a given place directly.
For all these topics, I think we need to create PRs, go through the changes and choose/find the best solutions. The branding CSS work you are doing in #2521 is an excellent example of that.