The best codebases I found myself working on had their folders structured around the features the app provides.
Some folks might tell that it is ...
For further actions, you may consider blocking this person and/or reporting abuse
I like the use of the file extension (
.component.js,.query.js) to denote the type of a file within a domain. However, personally I prefer to separate my concerns out a bit more.If I'm looking for something that updates a specific cookie, or fetches some data from an api, for example; I'd probably spend longer digging around all of those feature folders for it than if I had my service layers separate from everything else. I always know my api requests or cookie updates will be in the service layer.
I also like to keep presentational and non-presentational stuff as far apart as possible. The view layer should only be concerned with 2 jobs: rendering data, and emitting events. It should almost operate in a bubble where it doesn't know anything about axios, or fetch, or cookies. The underlying tech is not a presentational concern. But if you put your services directly next to your components, you're tightly coupling the entire stack of your application.
Ack I'm rambling about architecture again! 🤦
DDD honestly has been the best thing I've learned that helps with structuring business apps. When writing business apps, or just about any app that's more than trivial, you think in and about contexts. A domain exists within any app. There's a domain in everything. But if your app is more complex, you need to start organising it in a way that makes most sense. That's where DDD helps keep things localised, to keep them in focus when working in a certain context, because usually such apps have more than 2 or 3 contexts (or distinct features) that it needs to handle. DDD calls these bounded contexts.
Of course DDD is more than this so I recommend anyone to learn DDD if they want to get better at writing well organised, easy to maintain apps from the start. You don't have to read the blue book (there's too much stories at the beginning that can get you bored), but read a good book on applied, practical DDD, watch a few videos on Event Storming, to get a better idea about how to find bounded contexts, and soon you'll never want to structure your apps differently, whenever you start a new project.
True, DDD can help a lot in a sense of thinking into structured code. However, the pitfall (not only with DDD btw) is that decomposition (into structures) is most likely based on functional aspects.
Why is this a pitfall? Because it makes it prone to volatility of the business (rules). I suggest anyone to read the book Righting Software to understand more about this.
Doing decomposition right is a daunting task and few have mastered this.
Apps will always be prone to the volatility of the business rules. Doesn't mean it's a bad thing. It's just the way things are.
Who says it's a bad thing? I also just state that is how it is. This also means this should be taken into consideration while putting a system together if you want to be able to maintain the system later on.
If you look around hardly any system is build this way. If you look even further, this is where the systems start to fail. This means it is crucial to understand this fact.
I'm happy Juval Löwy wrote the book "Righting Software" so we can learn from his experience and hands on knowledge of decades building systems the right way. Systems build on time, on budget and with zero defects.
Cool... So is he the only one that wrote about how DDD system break down or whatever?
Interesting architecture. It's the first time I see an architecture without a page folder. Please, do you have a project with public source code based on this architecture?
I don't have any public examples at the moment. If I find or create, something then I'll share it with you!
This really feels like the way Angular apps structure their code. Which I like!
Really great architecture and completely different from what you usually see!
Awesome Article