The &quot;separation&quot; between your business logic and your view logic is really better thought of as a decoupling.<p>Let&#x27;s say for example that your application is a game of solitaire. Rendering the cards is a view concern. Interpreting UI events as game actions is a view concern. Accepting or rejecting those game actions is business concern. Animating that acceptance or rejection is a view concern. Persisting or restoring your moves or game state to an API is a business concern with some networking glued to the side of it.<p>That&#x27;s sort of a trivial example, but the event catalog for your application might look like this:<p>name: GAME_STATE, payload: A JSON representation of the card stacks<p>name: PLEASE_MOVE, payload: A representation of an attempted move<p>name: MOVE_REJECTED, payload: The card that tried to make an illegal move<p>A move event would result in a new state event or a rejection event. Your rendering components don&#x27;t need to know how that happens or who controls the state. Your core components don&#x27;t need to know if this game is being played on a server or a browser. Your move events might come from a swarm of multiple players. An analytics component can listen to the bus and fire off things that it&#x27;s looking for.