Odoo & Clean architectures

[flachica]

Food for thought:

I recently changed jobs. A product technology company where the use of clean architectures and care for code is very important.

It happens to be in this context that we Odoo people came in. With its central database, its framework and extensibility well known in our world. Some of my colleagues point out that Odoo is a very interesting monolith but suffers from bad practices.

The monolith thing "they buy it from me". You shouldn't demonize something just because it's not trendy. What they don't like so much is that we have to adapt to some practices that they don't quite see.

Has this ever happened to you?

I am considering that the models folder should cease to exist in favor of two new ones: one for the Odoo ORM to map tables and models and another one with the business logic.

Do you have any similar design?

On the other hand I was told that the "bounded context" in Odoo are not very well defined. In that I disagree a bit, there are modules and the boundaries are fuzzy, but they exist. Besides, this so configurable software cannot have very strict boundaries in my opinion.

Anyway, I think this is an interesting debate for this new forum.

[katyukha]

Hi,

A long time ago, i have implemented yamodool - proof of concept that allows to separate model definition (tables, cosntraints, etc) in separate yaml file, and in normal models, just define logic. The possible benefit of such approach - is following: possible compatibility layer between different odoo versions, ability to declaratively define complex fields (counters, sums, etc). But, it was never used in production.

Also, long time ago (OpenERP version 7) we have used similar approach: Model definition in one file, and all logic in another file. At that time, it seems that it was convenient. But looking at that code now (after years following standard when each model i located in separate file), it becomes inconvenient.

I think, it is better to follow OCA standards: this way it will be much easier to understand your code for any Odoo developer.
Also, following OCA standards will reduce confusion, when developer will look in standard odoo models or third-party modules.

[l-arnold]

IMHO some flowcharting and datamapping would be helpful. I am not (yet) a programmer in Odoo, but just running systems it can be quite unwieldy. Some modules change perhaps one field while others change a variety of things. A map of what is applied would be helpful... Sounds like another module I expect. Perhaps an App.

[yajo]

I imagine somebody telling Fabien at some point in history: "hey, monkeypatching is bad". And he thinking: "but I like it. What if we make monkeypatching maintainable?"

Odoo is monkeypatch-based software. It just maintains a collection of registries to maintain the monkeypatches oredered. It's the same everywhere: models, controllers, views, qweb, old-style js, new-style owl... This is its biggest strength and its biggest weakness. You just have to accept Odoo is designed the way it is and go with the flow. If you just don't want that, then it's better to use a system that's designed in other way, such as ERPNext.

Regarding models vs logic... IMHO that comes from the MVC paradigm. In Odoo, that differentiation gets blurred, because most methods become controllers automatically in the sense that they can be called directly via RPC. RPC is not REST, so it's way more flexible. What Odoo calls "controllers" is not what MVC calls "controllers". In that sense, Odoo fits better in the MVVM paradigm. Again, just accept how it is and go with it. You'll get into less trouble than if you try to make Odoo what it isn't:

This is just my recommendation based on my experience, but others might think differently and it's perfectly OK. 😉