But, just as in the real world, information taken out of context can be confusing or unusable.
Within the context, we share a common language and the design is coherent and unified. Why context? Because each context represents some specialized knowledge in the solution. We use the phrase bounded context instead of something like subsystem because it helps us stay focused on what’s important when we design a solution: being aware of the context and being aware of the boundaries. Each bounded context is a mini domain model in its own right. domains and subdomains in the problem space are mapped to what DDD terminology calls bounded contexts - a kind of subsystem in our implementation. If you know nothing about it, I recommend to read this Martin Fowler article before continuing.Īccording to the great book Domain Modeling Made Functional: Use a module on each app to act as a public API to exchange data between apps, and also to call functions to mutate data Īn app should never return its internal data structures on public apis, it should return only raw data like maps and lists
#Bounded contexts code
That’s the kind of mind-blowing post that challenges us to experiment different ways to write software, and that post is my practical approach on this matter.Īn app should never call internal code from another app What if we could write loose coupling services without the overhead of common microservices architecture? In 2015 Valim wrote an article entitled Elixir in times of microservices, where he elaborated his idea on how Elixir fits in a microservice architecture.
0 kommentar(er)
