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

[Oliver Korpilla]

Hello, Leif.

My biggest hurdle was understanding how an OTP callback module works and I resolved that for myself by implementing a behavior along similar lines to understand it. Somehow my brain did not click when reading Erlang books about it.

I never much worried about B) and E) as Erlang is so flexible when it comes to rearranging things later on.

Similarly, H) evolved over time.

C) is message passing in most cases. I occasionally employ calls but I'm relying mostly on message interfaces.

Regarding F)... I still have found no use case for an event handler in my project. And once I understood (with the help of the mailing lists and forums) how the loggers work it was not hard.

It was an interesting last year. Wouldn't miss it in the world. :)

Best regards,
Oliver
 
 

Gesendet: Donnerstag, 15. Dezember 2016 um 13:04 Uhr
Von: IRLeif <eric.fredheim@REDACTED>
An: erlang-questions@REDACTED
Betreff: [erlang-questions] How to think and reason when designing process- and message-centric systems?

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