That is precisely the question 
I understand this point. However I still have the following question:
- Given that the core should be functional, should we care about processes at all? Isn’t a process a runtime requirement that is independent from the functional requirements (the core of the application)?
I ask this, because when I used to work with Java (yes yes, I can hear you mocking me, that’s fine :P) we used to focus our application in the functional requirements, and only then if needed, we added threads for concurrency. I understand Java threads are a poor comparison to erlang processes but the idea I am trying to take out of here is how to organize workflow and to separate runtime concerns from other concerns.
I am not saying I don’t agree that we need a process. I think this is a sound solution that makes a whole lot of sense (and now that Supervisor follow, it makes even more sense) I am just asking if when you build application cores and, you already think about processes.
Perhaps this image helps explain my doubts:
So, I have the idea that Island, Guesses, Board, Coordinate, Rules and Game all belong to the core layer. OTP would be the layer on top, the Domain one, where we add processes, supervisors and support for fault tolerance / concurrency.
Perhaps I am miss-interpreting the lessons in the book, perhaps this onion model doesn’t really fit (perhaps both), but I am struggling to understand where each piece fits. This struggle is where my questions come from
@peerreynders He he, yeah, I would personally separate them. But now I am keen on knowing the disadvantages of coupling to OTP behvaiours (topic for another discussion).
Thanks for the code though, that is exactly the module I was referring to !
