Hammock thoughts

Before I started venturing down the path of designing an architecture, I already seemed to like Atomic Design by Brad Frost, and conversationally I seemed to think more in a domain driven manner. I started playing around with trying to combine the two. I liked the compositional nature of the Atomic design and started forming a basic design system. However, I felt that my main domain concepts did not fit into the system. I haven't "properly" learned Atomic design so most probably I'm missing something, but it didn't seem to click in practice.

Instead of focusing on a complex design system I decided to simplify it and focus on the domain aspect. I started to think in a manner of building a domain driven component library. The goal was to combine the domain logic with the components, achieving something similar to what the Atomic design system accomplished for a design system. I was hoping that I'll have components that encapsulate the logic and then the different pages will simply be a composition of these components.

I was hoping to reach a point were I could quickly create new pages, while keeping a uniform look and feel to each domain concept. All I would have to do is have a domain object id, pass it to a component.

This idea was looking great to me - so as every developer does, I over engineered it!

I already planned a large frontend team, and split them each to manage a domain concept. For a given domain entity I the given team would expose a component library for the given domain. Each team would also be in charge of several pages that fall (as closely as possible) under that domain. This would create an interesting tension as each team would, on the one hand, manage and maintain a component library (essentially a versioned api that the other teams use). On the other hand, they would manage a page which would utilize both their own library as well as components made by the other teams. That way each team would both understand how it is to be both a consumer and a provider.

After this way done I thought I need two more teams (more teams? yeah, why not). One team would manage the design system. This could be passed to the designers or split between the teams but I prefer having clear ownership. Then I needed a team to manage the packaging, deployment, authentication or what I call front DevOps. This team would be in charge of smartly bundling all the apps, routing between the modules (I had a few ideas but never had a good solution of how to do this effectively). They would also manage the global state and pass the required data to the whoever needed it.

I really liked this thought and wanted to try it out but it didn't really fit with the team...