Re:My 20 Year Career Is Technical Debt or Deprecated
by putnambr on Tuesday May 16, 2023 @11:39AM
(#35963342)
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.
Re:My 20 Year Career Is Technical Debt or Deprecated
by damethos on Friday May 19, 2023 @02:48PM
(#36005483)
> WidgetService can either import `ItemClient` or roll its own
Can you clarify what is ItemClient in your context?
Re:My 20 Year Career Is Technical Debt or Deprecated
by tracker1 on Tuesday May 16, 2023 @07:44PM
(#35969337)
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.
Re:My 20 Year Career Is Technical Debt or Deprecated
by arcbyte on Wednesday May 17, 2023 @10:07AM
(#35975394)
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.
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.