DEV Community

loading...

Discussion on: Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS

Collapse
jbogard profile image
Jimmy Bogard

So just an FYI - the project that originated the definition, I was the tech lead on, and we ripped out this style of architecture after about 6 months. For us it didn't scale with complexity. I talked about what we moved to at NDC vimeo.com/131633177

The long and short of it - layers don't encapsulate, they abstract. When we moved to CQRS-style architectures, just the object models that is, we were able to ditch all those service/repository layers in favor of queries and commands. The result was truly SOLID, as opposed to our onion architecture, which I finally saw as a gross misunderstanding of SOLID and OO principles.

Collapse
remojansen profile image
Remo H. Jansen Author

I just watched your talk and maybe I'm getting it wrong but it seems like you are not happy about the n-tier architecture, not the onion architecture. They are actually quite different (I have also experienced the n-tier pain).

n-tier

onion

More info at blog.ploeh.dk/2013/12/03/layers-on...

One of the things you mention is that you are able to change the used ORM tool. In the onion architecture, this is perfectly possible. In fact, we migrated from sequelize to TypeORM and it was a small job.

When a system becomes more complex, the onion architecture can be combined with the CQRS and the Unit of work patterns and when it becomes even more complex it can be split into "a bag of onions".

Collapse
jbogard profile image
Jimmy Bogard

No, this was an onion architecture, your second picture, not n-tier. Like literally the dude that invented the term, this was the project and we moved away after a few months.

So we start with CQRS and only add any kind of layering like onion as necessary. It's just been 8 years going CQRS-first, and have yet to really need any layers. No abstractions, nothing like a repository or service layer, nothing like that. Just unnecessary.

Collapse
hdennen profile image
Harry Dennen

"The long and short of it - layers don't encapsulate, they abstract." Effing nail on the head there mate. We've been slowly massaging our front end away from onion because of exactly that over-abstraction to the point of sprint velocity crushing complexity. It also lead to a lot of premature generalization.

Collapse
ajoshi31 profile image
Atul Joshi

I saw your video and seems its like coming back to square one after all the DDD, that that patterns, just simple separation of concern .
In one of my earlier project I was doing dividing the project based on the controller, model and service structure, then in new version I thought the feature separation will help, however eventually I felt that feature separation was making me more concerned as where to keep some files or function.

Like some functions need to be dependent on two or more features, where to create that folder structure, then many a times comes a lot of cross dependability, how those things can be taken care?

In that case I feel that a particular functionality instead of feature works better.