-
I’m re-reading Domain-Driven Design and I’m getting so much out of it. Something that is really interesting is that the modern day product engineer is often modeling two domains at once: the problem domain, and the design system (or visual language). amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215Permalink On twitter.com
Mood 0
-
A product engineer needs to uncover/learn/speak two different “ubiquitous languages” in different contexts — one for working with domain experts & one for UI/visual designers. There are occasions where the models and semantics may overlap, but the goals are ultimately distinct.On twitter.com
-
This may sound antithetical to the whole DDD approach, and in some ways it is — but it is the reality of the modern approach to creating unified company-wide visual languages (design systems) that can apply to multiple different products and therefore problem domains.Permalink On twitter.com
-
If it sounds complicated, it’s because it is. This is why dedicated design systems teams are needed — they are mapping a domain and building a product themselves. And it’s in the overlap of this domain and another product-focused domain that the modern product engineer lives.Permalink On twitter.com
