Hammock thoughts

I believe that other than the technical aspects of an architecture, it also sets up the team to what kind of discussions they are going to have. This is important if you want to set your team up for success.

While exploring design systems I stumbled across the Atomic Design way of thought by Brad Frost. It was the first framework that clicked with me. I loved the composability, the clear structure and validation that I'll avoid duplication. To be honest, I watched a few videos and jumped right in - I never actually read the book or spent the actual required time to properly learn this technique.

However, quite soon I felt like most of my discussions are revolving the questions of "is this piece a molecule" or "this can't be an organism yet...". These are definitely important questions if you would like to maintain a clear atomic system, but are these questions pushing the team forward?

No system is perfect and every system will have gray areas. That is where the discussion forms. I'm not implying that I have a perfect solution, only that I try to use the "down side" of the system as well. As essentially a system design is a framework for organizing logic - the gray areas are at the borders, when the cut isn't clear. If you structure those areas around essential questions that is what will be discussed.

I promise I will give the atomic design a proper try at a different time, but meanwhile I prefer to discuss business logic with my team. That's why I try to see what questions the proposed system opens and see if these are the discussions I'd like to have. I much prefer discussing "is this functionality part of the ui (ViewModel) or part of our domain logic (Model)?" or similarly "Do we have enough instances to create a reasonable abstraction or not?".

What would you like you team to be talking about?