There are some cases where some of the data on a class of the domain model of an application seems to be dependent on the technology being used. One example of this is the following: suppose we are building one application in .NET such that there’s the need of an Employee class. Suppose further that we are going to implement relational database, then the Employee has a primary key right? So that the classe would be something like
public class Employee
{
public int EmployeeID { get; set; }
public string Name { get; set; }
...
}
Now, that EmployeeID is dependent on the technology right? That’s something that has to do with the way we’ve choose to persist our data. Should we write down a class independent of such things? If we do it this way, how should we work? I think I would need to map all the time between domain model and persistence specific types, but I’m not sure.
1
No. You need an ID whenever you want to uniquely identify something. My id card/passport has an ID that uniquely identifies me as a specific citizen. This has nothing to do with it being a piece of laminated paper.
Likewise, you will probably need an employee ID for organizational purposes. I encourage you to re-use this existing ID in a database schema, but this has nothing to do with databases. Your confusion may have arisen by implicitly using a memory location as an ID for most of your objects. However, memory locations are only unique at a certain point in time, on one single system. Therefore, they cant be used for serializations.
2
Adding ID fields as primary keys (or also as foreign keys) is indeed a technological choice, since you would not need those for non-persistent data. In all OO languages I know of you can express relationships and references between objects without any artificial IDs, just by the way your programming languages offers references or pointers.
However, such an ID field will be helpful for lots of of different persistence mechanisms, so it is not dependent on a specific technology, only on the fact that you want to persist that data. In fact, using an ID field for relationships will be compatible with almost any persistence mechanism I know of. I remember that there had been some OO database systems in the past which tried to avoid the need of introducing additional ID fields, but using such a system and not introducing an ID field does make your program much more technology dependent than it gets with additional IDs.