When performing code reviews, one subject that always creates discussion is the data dictionary. The typical programmer pays little attention to the database layer and when writing a program that requires a custom table, probably gives very little thought to the design of the database. However, as many professionals coming from other enterprise application domains will attest, the definition of a table is not a quick decision. There are many books that discuss about the best way to design a database (table, fields etc.). Yet in the SAP space, because of the desire to make application development as simple as possible, little thought is given to the database design. In a typical client installation we see a growing number of custom Z tables and unfortunately, many are designed poorly. Having said that, let's focus on when to define a domain and when to define a data element.
When to define a domain
A - No need for a custom element
Firstly, the easiest decision to make is when a domain and data element already exists that exactly defines the data that is being referred to. It's an easy decision, and by default I would say only create an element when absolutely necessary. So for example, if I am creating a table to collect materials (let's ignore for the moment whether we need to or not) I want to add the material number field to the table. In this example, I create my Z table referring to the MATNR data element and there is no need for a custom data element or domain.
B- Need a custom element
Ok, let's describe another situation.
C - Example of needing a domain
In my last example, I am creating a custom table.
This should make it simpler during your code review to question the need for any of these elements and ensure that you create elements when you really need them and keep your DBMS as under control as possible.