Simplest Architecture to separate UI and business logic on Windows

Question

I guess the goal of separating UI and business logic goes way back. I found a Martin Fowler article, from nearly 20 years ago, which is pretty clear about the benefits of the separation: https://www.martinfowler.com/ieeeSoftware/separation.pdf

I'm undertaking a development where I believe the domain layer I develop will likely live a lot longer than the interface I create, so I'd like to design the domain in such a way that a future UI developer can easily "plug into it".

I have a couple of important constraints:

• The UI never needs to be used outside our local network.
• We are a "Microsoft shop" i.e. the technology used by developers in our company is very much focused on Microsoft technology. This is unlikely to change in the medium term.

Bearing in mind the constraints what is the simplest approach available to me, use Microsoft projects and solutions, to achieve this separation?

---

Edit

Some extra information: I'll likely implement the UI using WPF or WinForms. Future implementations may use ASP web form, or whatever MS are offering for web development. The application will have a couple of smallish (400 row) datagridviews that need updating every few seconds - I'm unsure if this makes it compute or data heavy.

Answer 1

The answer on this might strongly depend on the type of front-end you will be creating:

If it shall be browser-based and thus easily portable to multiple platforms, you might indeed consider providing a Web API in front of your business logic. This will come with all the advantages, such as the possibility to distribute GUI and business logic onto separate machines, etc.

However, if your front and back end are a native applications on the same machine, you might just want to put the domain layer into a (dynamic) library and the GUI into an executable that uses it. This will be easily configurable in MSVC (one project for the library, one for the front end, one solution that contains both). This is a very convenient approach to ensure that no front end specific code dissipates into the application layer if you: Please keep in mind, that the public interface of the library has to be well-designed and not tailored towards today's front end application. Otherwise, you will most-likely prevent replacing it in future or will have to write lot's of adapter code when re-using the library in a different context. In a larger team, you might want to ensure this, e.g. by a thorough code review at least for all changes to the interface.