consider the following simplified example:
public class Ticket
{
public int Id;
public TicketState State;
public Ticket()
{
// from where do I
This answer hopefully follows on from duffymo's.
In a DDD view of the world, your TicketState is an entity that is part of the Ticket aggregate (where a ticket is the aggregate root).
Following from that, your TicketRepository deals with both Tickets, and TicketStates.
When you retrieve a Ticket from the persistence layer you then allow your TicketRepository to retrieve the state from the DB and set it on the ticket correctly.
If you are newing up a ticket then (I think) you do not need to touch the database yet. When the ticket is eventually persisted, you than take the New state of the ticket and persist it correctly.
Your domain classes should not need to know anything about the database model that takes care of state, they should only need to know about the domain model view of state. Your repository is then responsible for this mapping.