[Izkata]

There's also a pattern based on the simple solution that used to be more common: One command-line program for updating and querying the current state, and a second GUI one that just acts as a dumb interface for the first one. Even aside from separation-of-concerns purity, there are two more practical benefits: this gives you scriptability (say, automatically choosing an environment on startup) as well as easier support for multiple desktop environments (two different dumb GUI frontends for the actual complexity in the command-line backend, or updating the GUI because of a change in the APIs without worrying about breaking the important logic).

[necovek]

Experience has taught us that the two operating modes are different enough by nature, that you need slightly different APIs for each (look at tools wrapping CLI programs: they generally suck one way or another).

What the industry settled on is building an API (library or service) around the data model and business logic, and then building UIs on top.

When done well, UIs are relatively shallow wrappers around the library, but do allow being creative about the UX too.