Breaking OFN down into Domains

Tech Exploration
21

Great, thanks for your feedback @kristinalim!

Circular dependencies
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 :slight_smile: 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 :slight_smile:

Performance overhead
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.

22

I’m not sure I follow the topic about API wrapper for APIs of domain-engines. Do you mean @kristinalim to have API calls to read from a domain to the other? I’m assuming that we still have a single app but discrete components that have clear boundaries and contract and not separate services in separate processes.

I share @luisramos0’s view

Actually, I want to see what exact code we are talking about here, and then we can decide where to put it

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.

Let’s move one and see how can make things adapt to our needs, which will change over time.

23

@sauloperez :+1:

API wrapper for APIs of domain-engines . Do you mean @kristinalim to have API calls to read from a domain to the other?

Yes, we will have domains depending on each others models but also we will have domains communicating through each others APIs. It’s easy to imagine on the frontend if you think that a angular page on the Web domain makes an ajax call to some backoffice api endpoint to get some data. For listing product on the Web this will be a reality very easily, right? Having backend code communicating through APIs, that’s a different thing to be thought/evaluated…

I’m assuming that we still have a single app but discrete components that have clear boundaries and contract and not separate services in separate processes.

Yes, but long term, as you start to have these components independent and communicating through APIs we can decouple even the deployment. Not something for now, but something to keep in mind because the need to decouple the deployment of web frontoffice from lets say backoffice catalog will come fast… this move is really strategic/long term, think 2025 :smile:

24

Understood.

That’s exactly what I wanted to clarify.

And

the need to decouple the deployment of web frontoffice from lets say backoffice catalog will come fast

That’s and interesting idea.

25

I have been improving the Domains wiki page with more details here:


Feedback is very much appreciated :smiley:

I am also trying to create a diagram with the vision for integrations with external systems based on these domains, work in progress here:

26

I would love to discuss that a bit in Porto if we have time when you won’t work on Spree… Your diagram seems really good, some bits are still unclear but we can iterate on it together with users use cases :slight_smile: