[erlang-questions] How to think and reason when designing process- and message-centric systems?

[Alex S.]

Hello,

what helps me personally when designing an Erlang system (as with any modular system, probably?..) is thinking in terms of responsibilities. E.g. each module is a provider of a certain service to everything else, whether it be a computational service (library module), interfacing service (db driver module, for example, or message codec), and/or stateful service (gen_server of some sorts).

I’ve yet to write an event handler although I’ve certainly used an excellent one that ships with lager ;).

One thing that helps mapping OO approach onto Erlang is thinking one module=one class (as in, a set of operations a state/actor responds to), and instances are created and passed around explicitly, be they server PIDs or other kinds of state. Do abstain, however, from creating «objects» which have no behaviour (so-called dumb objects), as you can just use data types for that; and from creating a multitude of «objects», as you’re then better off thinking of a whole collection as an object.

The process boundaries should generally be drawn along the lines of «What parts of my system wouldn’t notice if the other parts would die and be seamlessly reborn?», although of course simplicity is also to keep in mind, and rest_for_one and one_for_all supervisor strategy is there for you to introduce explicit dependency between parts of the whole that are split between processes.

Hope that helps! ^_^
> 15 дек. 2016 г., в 15:04, IRLeif <eric.fredheim@REDACTED> написал(а):
> 
> Dear Erlang community,
> 
> This is my first email to the mailing list. I apologize in advance if this is odd or off-topic.
> 
> Coming from an object-oriented and data-centric background, I have cognitive difficulties when it comes to conceptualizing, thinking about and designing systems consisting of modules, processes and key-value data stores.
> 
> My brain reverts to thinking about classes, objects, inheritance trees, encapsulation and SQL-style relational data models. I'm afraid this could lead to unidiomatic Erlang system architectures and implementations, which would be undesirable.
> 
> Here are some of the essential complexities I have difficulties grasping:
> 
> A) Identifying discrete modules and processes and finding good names for them.
> B) Appointing supervisor and worker modules; defining process hierarchies.
> C) Deciding which processes should communicate with each other and how.
> D) Designing a sensible persistent data model with Mnesia or other NoSQL data models (e.g. using CouchDB).
> E) Deciding which processes should read and write persistent data records.
> F) Incorporating global modules/"shared facilities" like event handlers, loggers, etc.
> G) Visualizing the system architecture, processes and communication lines; what kind of graphics to use.
> H) Organizing source code files into separate projects and directory structures.
> 
> Questions:
> 
> 1) How do you unlearn "bad habits" from object-oriented way of thinking?
> 2) How do you think and reason about process-centric systems designs?
> 3) When designing a new system, how do you approach the above activities?
> 
> I would appreciate any practical tips, examples, "mind hacks" and resources that might help.
> 
> Kind regards,
> 
> Leif Eric Fredheim
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions