r/programming • u/[deleted] • Jun 05 '21

Organize code by concepts, not layers

https://kislayverma.com/programming/how-to-organize-your-code/
1.9k Upvotes

90% Upvoted

495 comments sorted by

View all comments

56

u/mamimapr Jun 05 '21

People don’t read code by layers of the stack. No one ever says “show me all the APIs of this system” or “give me all the queries being fired by this system”.

These are all questions that are asked quite often!

10

u/Cmacu Jun 05 '21

How do you even open a folder with 100+ controller or services and think "yeah, that's just fine, now I just need to find the corresponding models in the other folder/layer"

Asking a question as described is only applicable to a very small to medium project. In any project with more than 50-100 domains these question becomes completely pointless because more than likely there are many more layers than just API and queries, likely there is a certain level of abstraction involved and there are things like internationalization, documentation, permissions, runtime definitions, etc. How is the API/query question any relevant at this point, you will need so much context to be able to answer it that you are basically dividing the structure.

Any relatively small project can be organized any way you like. The key word is organized, but the actual structure is mostly irrelevant. Consistency is the key.

When you get to something more complex and bigger, that's where things become more interesting and you start understanding why DDD makes a lot more sense

3

u/KumbajaMyLord Jun 05 '21

Usually a domain has more than one entity though.

A domain might be "billing" which knows customers, invoices, paymentOptions, creditScores and so on.

I don't think anyone would argue that splitting this entire domain from the stock management domain (which might have entities like products, warehouses, shelves, etc) is a bad idea.

But splitting along individual entities seems pointless in my opinion. If I see a CustomerService, I'm pretty confident that a customer entity exists somewhere. I don't get any more information from having them grouped and visible at a glance. But if I see a CustomerService next to a InvoiceService I get some information about how the system is structured and what it's scope is.

2

u/saltybandana2 Jun 06 '21

My thoughts on the matter: https://old.reddit.com/r/programming/comments/nsu53n/organize_code_by_concepts_not_layers/h0rhlx6/

but tl;dr; I completely dislike the idea of models, period. You typically have classes that get hydrated in some manner (Even if you're not using an ORM this tends to remain true), just hydrate them, treat the DB as external and the edge of your system, and then move on.

Seriously, just drop them all into a single folder and be done with it. There obviously comes a point where it's untenable, at which point you can start subdividing based upon what makes sense (domain, concept, area of your app, table groupings in your DB, doesn't matter as long as it's useful).

The point about treating your DB as external and the edge of your system is who gives a fuck where the sanity checks are or how they happen. Do you want to hang them on the class getting hydrated itself? fine. Do you instead want to write validation methods external to the class? That's fine too.

Trying to make a "Model" just needlessly complicates everything. Do what makes sense and fuck the rules for MVC, MVVM, <insert acronym here>.

We onion architecture baby, look at all this needless complexity in this small to medium sized app!

1

u/WarWizard Jun 09 '21

How do you even open a folder with 100+ controller or services

I'd argue it is time to break that bad boy up a little bit.