Designing data structures is most difficult when you're not sure how you will use them.

Which is most of the time.

Once your data and software processes are in place, what will you do if you get a new feature? If you have a new way of billing? If the word "Client" substantially changes in meaning, because you once sold directly to users and now you sell to enterprises?

The business needs are always changing. While the exact needs of the change are hard to predict ("just tell me what you want!"), the parameters usually are not:

• The times and option for receiving a payment may change, but we will always want to accept payments.
• We can't be sure that we will always want to communicate with the same external services, but we know that we will leverage some APIs.
• The definition of a 'secure' password may change, but we always want that level of security.

And to meet those needs as they arise you will have to either change the programming logic or you have to change the data structure.

Think about data structures like a mountain, and software processes like the trail. The data objects are geographical points -- waterfalls, cliffs, forests, outcroppings. The programming logic is that path from one geographical point to another.

Once the data structure is built -- and populated with hundreds of thousand of data points, it is more or less unmovable, like a mountain. But the software processes are more like a trail along the mountain, taking you from one data object to another along the mountain. Though it may take some bush-whacking, it is usually easier to move the trail than to move the mountain.

So as you are designing your data structure with your team, make your structures and objects flexible in the areas that are likely to change. Understand that you are building a mountain.

It is difficult to change the mountain; simpler to change the path.