Comment by cies | Hacker News Reader

Comment by cies | Hacker News Reader

Parent Full thread

I so much agree with this, I want to hug you.

All this encapsulation for sake of encapsulation, and interfaces everywhere even for implementations that the application is married to. I once heard a wise man say: most of these design pattern only add code! And we should be weary of adding code that does not add features. Sure in some cases it makes the code easier to understand/read/refactor. But in many cases it becomes a holy goal with very little actual benefits. Clean architecture being the epitome of this.

> data should be separated from actions that are being performed on that data

This view is shared by nearly all dev that prefer functional programming. I also consider this true. FP-langs help you to "keep 'm separated", and OOP-langs historically make this very hard.

If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.

>OOP-langs historically make this very hard

I don't think is just the langs, but mostly the old culture around those. I do .NET development using a data oriented approach and nobody calls me an incompetent developer. I also teach junior colleagues to be vary of OOP-ness for the sake of OOP-ness and overusing patterns.

I am not aware of any OOP language that demands inheritance, encapsulation or method overriding. It's the people who do.

>If you build an app on top of a db, you biz logic will get intertwined in the queries and the some of the code that's close to those queries (i.e. model code). That code represents you business logic. Trying to write the biz logic separate from the db is --to me-- just a way to make your project go over budget and hurt your performance.

I tend to separate, when possible, business logic from DB logic and from other kind of input like calling into external APIs. But I do that trough layers. I put a repository over the DB and its job is to just fetch data from DB and deliver it as data structures. I use that repository in a business layer.

> I am not aware of any OOP language that demands inheritance, encapsulation or method overriding. It's the people who do.

But in Java all functions must be part of a class. All I want to say it that in OOP-langs it is possible but takes a lot more discipline. Where in FP-langs there's lots of guard rails and help in making sure you separate logic from data.

> I tend to separate, when possible, business logic from DB logic and from other kind of input like calling into external APIs. But I do that trough layers. I put a repository over the DB and its job is to just fetch data from DB and deliver it as data structures. I use that repository in a business layer.

I find a lot of biz logic ends up in our db queries in order to make things fast. Running the biz logic in the db yield big perf improvements. I cannot see how to do that in a layered approach.

The biggest reasons for me to use the clean architecture are faster testing (most logic is in functional code) and most changes having impact in a small number of files only.

Reply on news.ycombinator.com