Does the following image depict it correctly?

[thomas-adriano]

I'm trying to come up with an image of the main goals related to isolation, responsibilities, separation of concerns and flow of control that the style guide proposes, could you tell me if it's accurate? If not, what would you change?

It's inspired on the Clean Architecture diagram, but with a few tweaks like having ORM at the center instead of Entities, since django is completelly dependent on its ORM. Also, in this version most (if not all) business rules/use cases lives on services/selectors.

• The arrows represents the flow of control, no interaction/reference should come from inside out, only outside in;
• Each layer represents the isolation of each level of abstraction;
• The 1st layer represent all possible drivers of the software using the style guide;
• 2nd layer is basically infrastructure code;
• 3rd layer is where most business rules, transaction scopes and orchestrations lives;
• 4th (center) is where the models live, so all the data and a few simple representations of data (via model methods/properties);

[RadoRado]

Hello @thomas-adriano :wave:

I think this picture is quite accurate :+1:

I'll try summarizing how I understand the Django Styleguide:

At the framework level (views, apis), you communicate with the "outside world", as defined for your application:

1. We can safely say that this is the "infrastructure" for our application.
2. All kind of parsing & data transformations can happen there.
3. Sometimes, you need to ask the "core" for things and take decisions, based on those things.
4. And usually, this layer cares about API related stuff - authentication, caching, rate limiting, etc.

Where I draw the line, for this particular layer, is when it comes to doing application / business logic.

This is for the services & selectors. Or however you'd like to call them 👍️

My mental model is: "The app should be able to work even if there are no APIs in play."

And this solves the question, related to abstractions around Views / APIs (having all your CRUD operations done by the API layer, for example)

Now, how you handle your "core" is entirely up to you.

Best case scenario:

1. You have value-objects (pure python classes) going in and coming out of your application / business logic layer. I think those are the "entities" from the clean architecture diagram from above.
2. And then something else syncs those value-objects with the ORM.

My problem with this is a simple one - in most cases, it's not practical at all. And you can simply use your ORM for those value-objects.

Now, there are cases, where you want to implement things with pure python objects and those cases, if practical, are great, because you can have proper unit tests that are not touching the database.

My mental model & the Django Styleguide is quite influenced by the "boundaries" concept for a functional core & imperative shell, as described here - https://www.youtube.com/watch?v=yTkzNHF6rMs

And so far, it's working really well for us.

The thing that most often pops out is - "How do I structure this particular Python module, so things that should live together, do live together?"

[thomas-adriano]

Great. About that part:

`Best case scenario:

1. You have value-objects (pure python classes) going in and coming out of your application / business logic layer. I think those are the "entities" from the clean architecture diagram from above.

2. And then something else syncs those value-objects with the ORM.

My problem with this is a simple one - in most cases, it's not practical at all. And you can simply use your ORM for those value-objects.`

Completely agree. You sacrifice practicality for theoretical correctness.

Thanks for the fast reply, @RadoRado helped a lot.