Does an in-code enumeration provide a stronger domain model than a static database table?As an example, say I have an Marble entity, with a Color attribute. The color attribute has a finite set of possible values—say red, green, blue. Say the database team recommends having a static S_ValidColors table, to the effect of:-----------------------| ColorId | ColorName |-----------------------|    0    |    Red    |-----------------------|    1    |   Green   |-----------------------|    2    |    Blue   |-----------------------Whereas I'm thinking more along the lines of (this is just a sketch for the general concept):public class Color {    public static const Color Red = Color(0);    public static const Color Green = Color(1);    public static const Color Blue = Color(2);    private Color(uint typeCode) {        ...    }    ...}Aside from the question of which is better (which probably depends on any number of other factors not represented here), is this a question that touches how strong the domain model is? Is one way more anemic than the other?
Does an in-code enumeration provide a stronger domain model than a static table?
domain model;enum
It entirely depends on the use of the enum.  If they are going to change often then in the DB is better, you don't want to recompile and redeploy once a week because Joe changed his favorite color again.  If the enum is more fixed then hard coding it will be better, it is easier to reason about and less likely to get broken. Do you need to access it from stored procedures?  Might be a good idea to have it in the database where both stored procs and regular code can access it. You really don't want the headache of maintaining two different versions of the same thing.  What does the logic that uses this enum look like? There are situations where either option is more practical.As far as the anemic domain model thing goes I don't think it applies.  As long as the domain model enforces the domain model's rules and processes, then the domain model is not anemic.  Storing values in the DB just makes them more dynamic and easier to change(which could be a bad thing given the right assumptions.)