Hacker News new | comments | show | ask | jobs | submit login

I'll give a proposal now: every chair of every developer shall from now on give them electric shock whenever they use the term "business logic". Ouch.

Seriously, "CreatesContact" is not really a class. It's a procedure, function with side effects, whatever you call it. Just with a class wrapper that boosts the developer ego almost as much as an AbstractFactoryManagerFactory.

No, modules are actually great. If you have billions of tiny modules all over the place, you probably (note the "probably") optimized way too early by splitting things out into them without a clear reason.

And guess what, if a new developer comes into a project and investigate stuff, they will see the model class start with all sorts of metadata, including callbacks, including those fancy ones called "before_save". If they can't guess what "before_save" means, you might want to either pay for an English class, or switch the framework to something that speaks in German.

And as for using rails as a web delivery mechanism, can you please, please, please investigate things like Sinatra and plain old rack, because those are delivery mechanisms. Rails is a framework, and it's entire point is being opinionated. If you disagree with the opinions, you probably should investigate other frameworks, or just use the libraries that you like (including those that are parts of Rails). Or maybe whack Rails into whatever shape you would like you to be in.

(Also, monolithic applications happen to the best of us, but the problems in them actually often come from the fact that they're monolithic. Stop looking for other developers to blame).

So... The department says if the sales recept is over $10,000, the system must present the user with another form that must then be approved by two managers before the request is continued. Where does that code live, and what do you call it?

I call it business logic.

A class that has a name that's not a noun should always be suspect, imo.

> give them electric shock

even better, force them to use COmmon Business Oriented Language

They should also use principles from the Object Management Group.

and after they finish building the system with separated business logic, suggest their business client to add a formal business requirement that all data should be persistently stored. just in case.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact