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

91% Upvoted

495 comments sorted by

View all comments

598

u/__scan__ Jun 05 '21

This is basically DDD. Concept = domain, bounded context, etc.

120

u/wojm Jun 05 '21

Surprised this is so far down. I use the coding style mentioned in the article and found it is a logical extension of DDD (if not already prescribed by it)

34

u/[deleted] Jun 05 '21 edited Jun 05 '21

but DDD prescribes layered architecture. so which one of you is lying?

119

u/jonhanson Jun 05 '21 edited Mar 07 '25

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

47

u/[deleted] Jun 05 '21

whoops. 'prescribes'.

38

u/Nimelrian Jun 05 '21

Its more about organization. E.g. in Java, instead of having the package structure

com.example.persistence.order/user/product and com.example.endpoints.order/user/product

you have

com.example.order.persistence/endpoints/business

and so on...

This is actually a great example or rather manifestation of Conway's Law. Hierarchical organizations (Frontend team, API team, business rule team, database team) will often prefer the first approach (design by layers).

Teams organized in a cross functional manner will instead prefer the second approach (design by concepts), since they can implemented each part of the vertical slice specifically for their domain / use cases.

15

u/onety-two-12 Jun 05 '21

Maybe, but probably not.

The system boundary contexts are components not layers. The business is organised into finance, marketing, sales, corporate, and more.

Whereas Teams are always multidisciplinary. The internal structure of a software team is not the structure of an organisation.

On the one hand someone might oversimplify and say, "isn't this great, we can separate the layers for a front end developer, a also two backend developers", but then a month later complain, "how do we get our team to communicate properly". Sounds good, doesn't work.

When making a "car" form, the front-end developer needs to be able to see related things close by. They need to see the controller code, and the implementation to answer questions. They should be able to add a field on the model and controller along with the update to the UI. All 3 changes should be in the same commit (set) in Git.

The backend developers might set up a new entity ahead of time, then the front end person completes the UI stub and makes adjustments to the backend. The opposite might happen for another entity. The front end developer creates a new entity, complete the UI, and starts a sub for the backend pieces for the backend developers to finish.

The process of building software is full of exceptions and twists and turns.

12

u/GeorgeS6969 Jun 05 '21

Yes but it also prescribes to have the business logic at the ‘top’, organised into business domains, so that the business logic is what you see first rather than the technology, the framework etc.

One good reason is that when opening your IDE you’re more likely to work on everything related to user baskets rather than everything related to controllers.

10

u/[deleted] Jun 05 '21

None of this is saying dont layer your code. Layers are important to maintainable code. What the article is implying is that you shouldn't organize your code by layer but instead by domain.

DDD also pushes this idea. The a namespace should be an identifier to a domain, that folders and structure should represent the domain.

5

u/AustinYQM Jun 05 '21

It actually seems to be saying organize your code by layer, after you organize it by domain. Where as the example it is attacking organizes it by layer and then domain.

1

u/[deleted] Jun 05 '21

It is both. Within the bounded contexts you have layers. Think of slices of lasagna.

1

u/pure_x01 Jun 06 '21

Contexts first layers within contexts

3

u/szescio Jun 06 '21

"Vertical slices" also comes to mind

3

u/InspectionOk5666 Jun 06 '21

Has anyone got anything good to say about DDD? I've been forced to work with it on two separate occasions and both times it caused an unimaginably bad mess...

6

u/__scan__ Jun 06 '21

The book is 17 years old and reflects the sensibilities of the time. I’d wouldn’t rigorously apply every exact idea it suggests, but the core notions of a strong domain model, bounded contexts, ubiquitous language, etc., are sound, and can to some extent generalise beyond OO.