Plan the Architecture and Solution Design
Start from the lifecycle, not the code
Architecture questions usually ask where something lives rather than how to code it. Learn the layers: an LCS project holds environments and assets; a Tier-1 development VM carries Visual Studio and a local database; cloud-hosted dev/test and sandbox environments are Tier-2 and above; production is managed through the Microsoft service. Code moves between them only as a deployable package produced by an Azure DevOps build pipeline, never by copying files.
Models, packages, projects
A model is the unit of metadata you develop in and reference from. One or more models compile into a package, and the package is the deployable unit. A Visual Studio project is only a view over elements inside a single model. The recommended practice is a dedicated model per customization or ISV solution so dependency chains stay acyclic and hotfixes stay independent.
Extensibility first
Overlayering is gone. You change Microsoft behavior with table and form extensions, Chain of Command, and event handlers. When no seam exists, the correct answer is a Microsoft extensibility request, not a workaround.
Patterns worth naming
SysOperation for batch and dialog processing, SysPluginFactory for pluggable business logic, business events for outbound notification, and data entities as the shared contract for integration and reporting.
Trap: options such as one model per class, or two models referencing each other. Circular references are not allowed and per-class models are over-engineering. Rule of thumb: design in models, deploy in packages.