It’s not uncommon in an application to have different representations of the same concept in different contexts. For instance you may have a concept encoded as a domain object and also as a type in a message contract. In this case you will generally want to use the same name in each context. However this has the disadvantage that the class name is now somewhat ambiguous. In such cases there will likely be at least one place in the code where you will need to refer to both contexts. This necessitates a mechanism for distinguishing between the types from...
A practice that I occasionally encounter is having the database to be used by a system entirely “designed” upfront before development starts. This practice implies that the data structure an application requires may be anticipated before the code is developed. Practical experience shows this view to be at best naive. Attempting to fully anticipate the needs of a system upfront is an exercise in futility. Any business system complex enough to be worth considering as a project will have facets that only become apparent as the system is constructed. Additionally as a development team works with a problem domain...