There's more...

When a solution is designed, it will be done by breaking the solution into packages of functionality. This is a normal design paradigm that has now been implemented (and, to an extent, enforced) within SCM. This means that our solution design will now define the various packages and their dependencies. In the case of SCM, a Package is a deployable unit.

We can make a hotfix to a package and, technically, deploy it separately to other packages in the solution. Although this is possible, we would normally create a release of packages as a deployable package. A deployable package is a collection of one or more packages that contain both the built code and the routine required to install them. This process is simplified using a build server that performs the build process for us, executes any tests, and creates deployable packages that we can then apply to our test environment.

There is a further level within SCM, which is a model. A model is a subset of elements, such as classes, within a package and can be used to move code from one development system to another, for example. A model can only belong to one package, and a Package can contain one or more models. Each package becomes (effectively) a Dynamic Link Library (DLL), which has to have references added in order to see elements in order packages. Because of this, we should use a limited number of packages. As a guide, we tend to have one package for mainstream development. To simplify the management of development tasks, we tend to have a project per Specification/Technical Design Document (TDD), all within the main package, simplifying multi-developer projects. Just like working on complex C# projects, we can perform code merges, branching, and shelving within Azure DevOps. This means having a label file per project; otherwise, we will have a conflict each time we check in a change to the label file.

Layers have been a core part of prior releases from its first release but are no longer that significant. As a partner, we still use the VAR layer and recommend the same guidelines as before to customers, but since we avoid over-layering, this feature will not be covered in this book.

The dependencies are defined against the package, not the model. When we create a project, the project is associated with a model. It is typical, and desirable, to keep this structure simple and only have one model for each package and to give both entities the same name.

The following diagram shows a typical Package, Model, and Project structure:

The ApplicationSuite package is a standard package that we normally always reference as it contains the majority of the types that we usually need. The arrows in the preceding diagram indicate the reference direction, showing that it is not possible for the Vehicle management package to see the elements that were created in the Vehicle management reporting package.