Namespace and Assembly Guidelines
Naming Convention Definition:
A set of standards that create a well-organized object model as well as an easily understandable assembly file folder structure.
Naming Convention Justification:
The Primary Technical Imperative in Software Development, as defined by Steve McConnell in Code Complete 2, is to “Manage Software Complexity”. Enterprise applications are inherently complex.
Proper usage of .NET namespace and matching Assembly folder structures will have these advantages:
Map Business Entities to Development Assembly Structure
Organize Assemblies into related Software Entities
Create a .NET Entity Object Model that groups related Functionality
Prevents Naming Conflicts with Common Dependency Entities
Facilitates Multiple IDE Solutions that consume Common Dependent Assemblies
Prevents Class File Explosion within a Single Assembly Root Folder
Organizes Like Files into Folders that map directly to the Assembly namespace
Reduces the Cost of Development and Learning Curve for Change Requests
Facilitates Logical Refactoring based on Related Functionality
It is the professional responsibility of all Enterprise Developers to be cognizant of this primary imperative.
Namespaces should follow the [DomainEntityName].[AssemblyName].[Purpose].[RelatedPurpose] format where the DomainEntityName is the root business functionality name and the AssemblyName is the functionally that is support the Business requirement. The functional purpose of a Type using the Namespace can be in a hierarchical structure.
The naming convention for the assembly will define the root namespace. The folder structure of an assembly will always define the appended namespace. Every software entity’s namespace will be name the same as the folder in which the file resides. This will help prevent naming conflicts with like named entities.
All Namespaces will use Pascal casing and separated by a period. Exceptions to Pascal casing can be made based on legacy and business requirements. This will be on a case by case basis and not adhoc. Acronyms can be used as caps when they bring better business understanding.
Pluralization can be used when it adds a better understanding to the intent of the Namespace.
Never name a Type the same as a Namespace. This creates an Assembly and Class ambiguity for fully qualified names.
Do not use generic names, keywords or other common names to Namespaces and Assemblies as this could create ambiguities as well
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services