Is there a “shortage” of Erlang/Elixir patterns? Maybe, maybe not:
http://erlang.org/pipermail/erlang-questions/2007-October/030091.html
Garrett Smith attempted an Erlang specific repository but contributions stalled.
And even if a prescriptive pattern was followed - it could still be wrong if it is applied in the wrong context (this is a real problem in OOP with respect to design patterns).
Ultimately Game is just a process manipulating some data structures (Board, Coordinate, Guesses, Island, Rules) - and Game itself is going to be part of a supervision tree which itself is part of an OTP application.
For a discussion on how to structure supervision trees: The Hitchhiker’s Guide to the Unexpected
Data structure vs Process: To spawn, or not to spawn?
Structured Programming Using Processes (2004)
Building applications in INSERT_TECHNOLOGY_X_HERE doesn’t change how good applications are built
Yes, but going from Java to C# isn’t changing the paradigm so the solution shape isn’t impacted. But going to Erlang/Elixir you are shifting paradigms into “Concurrency Oriented Programming” which means that processes and most of OTP becomes part of the Core rather than being a
What seems to currently be challenging you the most is that a process can be an entity.
I’ve commented on the onion architecture before and in my view the most insightful aspect was that the domain layer gets to dictate the contracts while the infrastructure has to implement those contracts (e.g. nothing in the data store is influencing what is going on in the domain).
That particular advice still applies to Elixir - if that is the type of system that is being built.
Most of these architectures boil down to examining the structure and characteristics of a system along certain dimensions:
- Boundaries
- at all levels of granularity (types, user defined types (modules), processes, supervision trees, applications, systems)
- physical vs logical boundaries
- (high) cohesion of logic within any one boundary
- (low) coupling between boundaries
- dependencies from within the boundary
- dependencies on the boundary
- i.e. good inter-boundary contracts (hiding implementation details, correct (specification → implementation) direction, etc.)
Alongs those lines what are the problems that you see with the design of Game?
Now there are some games you can play to hide whether or not something is a data structure or a process. But processes that are part of a supervision tree are known to be processes - otherwise they couldn’t be part of the tree.
