Behaviours without code that consumes them seem odd; usually they are used to communicate “this generic functionality needs the following callbacks for your specific needs”, like how you implement the GenServer behaviour and then pass that module name to GenServer.start_link.

Hi, @stevensonmt!

I’m trying to introduce this approach in a project I’m working on to make business logic a little more explicit and to help onboard new developers. It goes something like this:

One project holds all the contracts that define how we interact with “objects” from the domain, those behaviors act like interfaces, that are later implemented by the “real” project, which must satisfy the specification. It’s pretty straightforward.

Another good example that you already mentioned, is how adapters in most library work.

BTW, IIRC a library that also does something like this is Cameonin; which is just a specification for password hashing libraries.

PS.: If you are planning on implementing ECS using processes, bear in mind that your might have a bottleneck. I’d recommend watching this video about it a Dwarf Fortress simulator in elixir:

Thanks! Comeonin is exactly what I was looking for as a model. Regarding the ECS implementation, this is really just a learning exercise so I’m not too worried about the bottleneck potential right now. I’ll check out the video though to avoid any avoidable design mistakes.