[erlang-questions] Using processes to implement business logic

[Garrett Smith]

On Fri, Jan 30, 2015 at 11:03 AM, Camille Troillard <lists@REDACTED> wrote:
> Hi Garret,
>
> Thank you for taking the time to answer my email.
>
>
> On 30 Jan 2015, at 15:45, Garrett Smith <g@REDACTED> wrote:
>
>>> I am looking for opinions about using processes to encapsulate the state of business entities.
>>
>> By using the term "business entity" you've tipped your hand I'm afraid :)
>>
>> It's hard, and not productive in my experience, to map RDBMS and/or OO
>> modeling concepts into Erlang. People do it, try it, etc. - but I just
>> don't think it's a good fit.
>
> Sorry if the term entity was confusing, I was not using it this way.
> As I did not want to go into the discussion of Object Oriented Programming, I tried to find a less opinionated word for a “thing”, part of the domain model. You’ll noticed that I did not talk about mapping a RDBMS either, just persistence.
>
>
> [...]
>
>> A process is an independent thread of execution. So if you have any
>> sort of independent activity in your app, you'll need processes. You
>> in fact might not. If you're building a web app, processes and their
>> lifecycle are handled by the web server - you'll just feed it
>> functions. Where are the business entities here? Don't look for them.
>
> I don’t see how the implementation of the business logic as to do with the external interface (web server).

It doesn't go with it at all. I'm just saying here that a process
should be used to implement an independent thread of execution. In
many web apps, the only independent thread of execution is the HTTP
transaction. So it's possible, in your case, provided that you're just
serving HTTP requests, that you don't start a single process yourself.

The implementation of business logic is via functions.

But you were originally going down the path of modeling. This is what
I'm suggesting you not worry about.

The glaring exception to this of course is if you're building an
actual model - like a simulator - where you want to see "users" coming
to life and behaving various ways. Here you would certainly represent
the users as processes.

In a typical OLTP application, you would not do this - you'd handle an
inbound request, perform some operations - usually against a database
- and return a result. The *process* here is the act of handling that
request, not in modeling some abstract "entity".

> [...]
>
>>> Now another question... given this “actor” based approach, I am having difficulties to figure out a proper way of dealing with processes lifetime. How would you do this in practice? Manually, or implement simple garbage collection, reference counting, ...?
>>
>> Sticking with "user" as our business entity (sigh) what's its
>> lifetime? Unless you are building a simulator where users come and go
>> quickly, we're certainly not talking about representing a user with a
>> process. For me it's very hard to even think of a "user" as existing
>> at all in a typical businessy app. You have "user state" - and that
>> will be initially created by some *activity* or trigger - e.g. some
>> HTTP request from a web app (someone clicked "Create User" on a web
>> form). Then some other event comes along - maybe a timed cron job -
>> and it checks some state of a "user" and performs some work. Or
>> someone requests a web page and you have to read user state. It's all
>> activities here (processes) and logic (functions).
>
> Again, I don’t understand why the web server would have anything to do with the of implementing a user as a process or a record. That does not rule out the possibility to modelling a user entity (or actor, or object, whatever you feel comfortable with) as a process.

It does not rule it out.

I guess I'd ask, what is motivating you to consider using a process here?