Separation of presentation and domain

Overview

Presentation Domain Separation is the design principle of separating user interface code from other code.

Layer Separation

Separating the domain layer from the presentation layer is especially important.

• presentation layer Interact with the user (implement commands and event handlers, provide a user interface, display/output results, etc.) and avoid including domain logic.
• domain layer It realizes operations for concepts such as design information, so-called domain logic, without being aware of the state and display of the user interface. There are models that represent concepts and states related to the domain, and services that provide operations on multiple models.

This keeps the software logic completely separate from the UI, making it easier to unit test. Since the behavior of the application is in the domain layer, reusability is enhanced, and in the future it will be possible to execute the extension function in CI or to make it a command line application.

Separating projects

It is very important to maintain the principle of separation of presentation layer and domain layer in architecture, but in order to prevent careless violation of responsibility, it is recommended to separate presentation layer and domain layer into separate projects. Highly recommended.

• Presentation - MyExtension.csproj Browse NextDesign.Desktop and UI libraries. We recommend .NET Core 3.1 as the target framework.
• Domain - MyExtension.Core.csproj Only reference NextDesign.Core and non-UI libraries. The target framework recommends .NET Standard 2.0, but if the referenced library has .NET Standard 2.1, it will be .NET Standard 2.1.

This separation ensures that there are no references from the domain layer to the presentation layer. If you don't separate the projects, you may accidentally refer to them and find that a dependency has been created.

Separating projects not only by layer but also by function eliminates dependencies between functions.

Accessibility controls

Even with project isolation, external references to various classes are still subject to internal design changes. Therefore, only the classes and methods that serve as entrances from the outside are made public, and the other classes and methods are kept private. The things to be disclosed to the outside should be kept to a minimum, and even if the logic changes and functions are extended, it will not affect the user side. See Hiding the implementation with accessibility for details.