When You See Abstract Structures, Design Becomes Easier

While developing an e-commerce system, I once designed a model called DeliveryDateConstraint to represent delivery restrictions decided by sellers. At first, it looked simple enough: each product had its own shipping rule.
But later I realised that customers and delivery schedules also limit when a product can actually arrive. All those conditions could be described as “available dates.” That discovery led me to extract a value object named AvailableDateSet. At that moment I felt that abstraction is not invention — it is discovery.

Seeing Structure Enables Generalisation

Originally, the model handled only the seller’s side.
Then I noticed that “available delivery dates” were nothing more than an intersection of date sets.
From this point of view, a seller, a customer, and delivery timing all share the same structure: each provides a set of dates, and their intersection defines what is possible.

earliest_delivery_date = (
  customer.preferred_delivery_dates &
  product.available_delivery_dates &
  shipping_schedule.available_delivery_dates
).min

Generalisation happened not because of creative imagination, but because I recognised the underlying structure — a set.

Knowing common data structures such as sets, ranges, trees, and graphs gives us a language to describe problems more precisely.
Once we have that vocabulary, we can see through the surface of business rules and find simpler, reusable forms beneath them.

Standard Libraries as Dictionaries of Structures

Language standard libraries are, in a sense, museums of reusable structures.
In Ruby, for instance, Enumerable abstracts the pattern of iteration; Range represents an interval that can apply to numbers or dates; and Set formalises an unordered collection of unique elements.
Each of these abstractions was born from many developers solving similar problems and then recognising a pattern that could be generalised.

Reading a standard library is like reading a dictionary of abstract data structures.
You can find how earlier engineers captured everyday patterns—iteration, ordering, containment—and turned them into composable building blocks.
Those structures often provide the missing words we need to express our own domain models more clearly.

Knowing Structures Lets You Delay Design Decisions

When I introduced AvailableDateSet, I didn’t need to handle every type of restriction at once.
Because I knew the concept of a set, I understood that other constraints—customer or delivery-related—could later be merged through intersection.
Knowing these underlying forms lets you delay generalisation until the right moment.
You can start simple, stay consistent, and expand when reality demands it.

Conclusion

Abstraction in software design is not a leap of imagination but a process of discovering existing structures.
Those structures—sets, ranges, trees, graphs—are already part of the common language of computation.
They live quietly inside every standard library, waiting to be noticed and reused.

When you struggle with a complex domain, try looking for a familiar shape within it.
The right abstract structure may already exist, and once you see it, your design will naturally become lighter and more flexible.