We want to code to be as simple as possible. We don’t want it cluttered up with domain knowledge that the programmer shouldn’t need to know. Thus, whenever possible, we want to avoid putting something as domain specific as chemical products into the code. That’s why we think that putting chemical products as an enum into your code is probably a bad idea unless proven otherwise.

As a similar case, consider a course registration system. You wouldn’t want the code to contain any references to various courses that people should be taking. CSI101 may be “Introduction to Computer Graphics”, but that should not be in the code at all. That information should only be in a database row for the course. The course registration system code treats all classes the same, only perhaps considering properties of the course such as name, prerequisites, credit hours, etc.

So the first question is whether you actually need to have references to the various chemical compounds in your code. This is independent of whether or not you are using lookup tables. Chemical.GetDensity(Compound cmpd, double concentration) can work just the same whether Compound is a enum, object, string, or int. StorageTankCluster.Generate(Compound cmpd, double requiredVolume), is the same, the function works the same whether or not the Compounds are actually named entities in the code. None of these things remotely require you to reference compounds in your code.

Of course, somewhere you have to specify which compound is being considered. It can’t always be a parameter to your function. It is the nature of that specification that determines whether or not you need to have reference to the chemicals in your code. Your statements seem to indicate that the business process determines which compounds need to be considered. I gather that the business process is written into code, and that’s why you need to refer the chemical compounds in code. But the question is whether the business process really needs to be implemented in code.

To see what I mean, lets look back at the course registration. Suppose that you’ve got a class with a complicated rules for whether you are allowed to take it.

boolean CSI250::MayTake(Student student)
{
    // if the student has special permission, he can always take the course
    if( student.HasOverrideForCourse("CSI250") ) return true;

    // Student must have taken 101 first
    if( !student.HasTaken("CSI101") ) return false;

    // Student must have at least a B in CSI 101
    if( student.GetGrade("CSI101") < Grades.B) return false

    // Student must have taken either CSI150 or CSI201
    if( !student.HasTaken("CSI150") || !student.HasTaken("CSI201") ) return false;

    return true;
}

If I understand correctly, you need an enum because you are referring to various chemical products in your process like I’ve done for courses above. (I’ve used strings, but I could have done enums just as well.) But the above code wouldn’t be a good idea, because it puts too much domain information into the process. It’ll be a pain maintaining it as the powers that be tweak and adjust things. So what we’d rather do is store the prerequisite information in the database, something like:

Course   Prereq    Grade Required   Alternate    Grade Required
CSI250   CSI101    B
CSI250   CSI150    D                CSI200       B

Now the prerequisite information is moved from the code into the database. It can be manipulated by the administration, the code is simpler, etc. The question is whether you can do the same for your business processes. There are many benefits to be had by moving something like that out of the code into data. Maybe you can’t, but its what I’d look to do.

I’d probably avoid enum even if you have to put these entities into the code. enums are pretty stupid. I think it’d be better to be able to say: Chemicals.SodiumPhosphate.GetMolesFromMass(1000) than to say GetMolesFromMass(Chemicals.SodiumPhosphate, 1000). It also gives you future flexibility because the method can do whatever it wants. It can use a lookup table, or store the data inside, or whatever.