4 ms·

> If you're working on a part of the code base you should just have to change classes in one single folder. A new feature should just be a new folder. That chan

> If you're working on a part of the code base you should just have to change classes in one single folder. A new feature should just be a new folder. That change alone speeds up teams by huge factors. This is a neat idea. Have you done this in practice, and how does it work over a long time frame? One of the big advantages of separate packages is purely for references: The model package has no reference to service or database code, so it's not possible to include SQL or other hidden service calls in it -- at least not without adding a new dependency which makes it blatantly obvious you're doing something wrong. On the other hand, if your features are self-contained, and you have good unit test coverage of all the logic, then I guess it doesn't really matter as much what the structure is. The fact it's unit tested forces it to be loosely coupled, and testability is one of the main reasons to organize code into layers in the first place.

putnambr 3y ago
Been doing this for a few years. If I have an `Item` class, it's going into its own package. Along with `ItemService` (business logic), `ItemResource` (endpoint), `ItemDao` (persistence interface), etc. If `Widget` has a dependency on `Item`, then `WidgetService can either import `ItemClient` or roll its own. Makes it super easy to split out microservices when the monolith gets big. Just keep from injecting one Service class into another, rely on the Resource or Client instead.
- damethos 3y ago
  > WidgetService can either import `ItemClient` or roll its own Can you clarify what is ItemClient in your context?
tracker1 3y ago
Been doing similar for years... I refer to it as feature oriented structure/organization. To me, that includes tests. I hate that so many code bases are effectively mirrored trees that are hard to break apart. You can still have effective layers, even classes if you like them. But there's little reason they can't live next to each other on disk in the same project even.
arcbyte 3y ago
To the extent I feel the need to do this (in very large projects with many teams) I think it's best accomplished with separate modules. My favorite way is a single repo muktimodule project with the core code in one module, all the database implementations in another, and very small third "main" module that brings them together and has the startup code. But there are other solutions. You could probably cook up some linters or some other compile time enforcer.

putnambr 3y ago

Been doing this for a few years. If I have an `Item` class, it's going into its own package. Along with `ItemService` (business logic), `ItemResource` (endpoint), `ItemDao` (persistence interface), etc. If `Widget` has a dependency on `Item`, then `WidgetService can either import `ItemClient` or roll its own. Makes it super easy to split out microservices when the monolith gets big. Just keep from injecting one Service class into another, rely on the Resource or Client instead.

damethos 3y ago
> WidgetService can either import `ItemClient` or roll its own Can you clarify what is ItemClient in your context?

tracker1 3y ago

Been doing similar for years... I refer to it as feature oriented structure/organization. To me, that includes tests. I hate that so many code bases are effectively mirrored trees that are hard to break apart. You can still have effective layers, even classes if you like them. But there's little reason they can't live next to each other on disk in the same project even.

arcbyte 3y ago

To the extent I feel the need to do this (in very large projects with many teams) I think it's best accomplished with separate modules. My favorite way is a single repo muktimodule project with the core code in one module, all the database implementations in another, and very small third "main" module that brings them together and has the startup code. But there are other solutions. You could probably cook up some linters or some other compile time enforcer.