The process of creating pretty much any dumb data object class, or even mostly dumb ones, is very similar no matter what those classes represent, at least so long as whatever data structure rules are in play hold true across the entire scope of those efforts. As more such data oriented classes are created, fewer new approaches to specific needs will be needed until eventually there will be a concise set of approaches for implementing various properties of all the various types and value constraints needed.

The BaseOrder class, shown here with BaseProduct, is a good example of that effect, at least at first glance:

The list of BaseOrder properties is very short, since all an order really represents is a customer relationship with a collection of products:

• customer is an instance of BaseCustomer, which in turn has the billing_address and shipping_address properties of that customer; apart from the fact that the type of the property's value is going to be a BaseCustomer instance, it's reasonable to assume that it'll behave in the same way that the Address type properties of BaseCustomer do
• products is a collection of BaseProduct instances that can probably behave exactly like the products property of BaseArtisan—it'll be doing the same sort of thing, after all, storing product instances and preventing mutation of those instances—so the initial implementation of it will be copied directly from BaseArtisan

In short, both properties, barring some changing of names in the case of the customer property, already have established implementation patterns, so there's nothing substantially new to show in BaseOrder.