<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 11:52 AM, Camille Troillard <span dir="ltr"><<a href="mailto:lists@tuli.pe" target="_blank">lists@tuli.pe</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It looks like, in the context of our problem, we should have more advantages implementing our domain model using processes rather than simple Erlang records. It also appears that processes will act as a nice cache layer in front of the persistent storage.</blockquote></div><br>In the words of the Subject/Object dichotomy[0]: do you want your business entities to "act" or be "acted upon" ?</div><div class="gmail_extra"><br></div><div class="gmail_extra">If the former is true, then make them into processes. This is often the case if your entities are "alive" and needs to query databases, have timeouts, needs to manage persistence and so on. Or if the processing of an entity is complex with many different advanced code paths.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If the latter is true, then make them into records. This is usually good if your data can be batch-processed and is just "dead" data, where other systems are using that data to work. This often leads to a pipeline processing chain where workers (subjects) operate on the entities. This is also the only viable model in many programming languages.<br><br clear="all"><div>[0] <a href="http://en.wikipedia.org/wiki/Subject%E2%80%93object_problem">http://en.wikipedia.org/wiki/Subject%E2%80%93object_problem</a></div><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>