[phillmv]

The solution you describe is isomorphic to the one proposed in the blog post, which I think you recognize?

But both leave a lot to be desired. I personally think in both cases they are a code smell, and we ought to either introduce an object whose explicit job it is to worry about these inter domain interactions or pile it up as a mixin into the appropriate domain models.

[briantakita]

The solution I describe is basically a functional approach. The function is responsible for the policy concerns over all data in the system.

The function itself can be decomposed into smaller functions.

If you need extensibility, you could make the function composable and register additional pieces to the policy. Most codebases don't need this sort of extensibility.

Simple constructs & consistent, accurate, precise naming is preferable to complicated architectures.

[phillmv]

:%s/function/module/ and no meaning is lost :).

I've yet to catch up on my lisp and fully grok the "functional paradigm" and, admittedly, passing around consts is less elegant than passing around function pointers, but what you're describing sounds isomorphic to me in terms of code organization. Look at the blog post; he's just passing a one method class, which… is basically a less elegant function.

[briantakita]

> :%s/function/module/ and no meaning is lost :).

Javascript has functions, from the function keyword. Node.js uses commonjs. In commonjs, every file is a module. You can use

module.exports = <value>;

You can access the module by using require.

var moduleValue = require("path/to/module");

It's powerful because it doesn't have the namespace collisions that Ruby has. Everything is not global all the time. modules are also an elegant way of holding private state using closures.

Having a class with a single method is the Ruby way of categorizing this method within the domain.