In the following image for the State Pattern from Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
I'm trying to persist the SalesOrder
entity into the database. Normally I would have a salesOrder
table in my database with a field currentState
pointing to the current state of the entity.
This implementation is fine as there is a single entity and its states only contain different behavior.
However, what if I had to track other properties for the different states? Examples:
- When a SalesOrder is cancelled I need to track the cancelled
quantity
,cancellationReason
,cancelledBy
,cancellationDate
. - When a SalesOrder is Refunded I need to track
refundQuantity
,refundPrice
,refundFee
.
So basically it is like I have a CancelledSalesOrder
and RefundedSalesOrder
entities with additional attributes. Same can be said for the other states as well.
So my problem now is that I will have to change the design from using the state pattern into using inheritance. However, inheritance doesn't allow my to dynamically change my state at run time (the problem which the state diagram solves initially).
so my questions:
- Does the state pattern fail when an entity in each state has additional attributes? what's the alternative?
- How should I persist my entities in this case? Single table inheritance? table per class? table per concrete class?
- If I have to maintain some attributes from a former state (Refund a Shipped order, but don't delete the Shipping address from Shipped state ), how would one approach this problem?
- How do you keep track of the order of which the states occurred?