I'M far from an expert in baking systems, and I've

Question

I'M far from an expert in baking systems, and I've

learned not look down on domain knowledge — building a system that can actually be used always requires much more effort compared to my intuition.

I have a few "simple" questions, after roughly examine the requirements.

1. Interest and minimum balance may change. How to prepare for the change? Is it worthwhile to simply put it a constant, at the cost of recompiling? Or provide a universal configuration interface?
2. I don't think a fixed type of accounts works in the long run. How to prepare for the change of "account types"?

From the perspective of low level things, many things should also be considered.

1. If the class is placed in a shared library, the "account type" change may break the binary compatibility. How to design the classes to minimize the cost of change? Is it worthwhile?
2. How to store balances? Floating point numbers surely won't work, but fixed point numbers are also tricky. Is the assumption that "two places after decimal point" correct in this scenario? Should the balance be signed? How to handle the overflow correctly? How to compute the interest if the data type is a fixed point number?
3. How to ensure the atomicity of operations? At which level should the enforcement be placed?

I can easily write more questions if I dig deeper. I won't write more, because the examples are enough to show my point:

Homework is simplified version of real-world problems. For a real-world banking system, the business logic is too complex that rarely a single person can comprehend. The homework only shows the tip of the iceberg, but the underwater part is usually what technical and design decisions depend on.

If you just treat homework as homework, not much can you learn from it. I think setting the bar low is not the optimal attitude — just write some silly code, who can't?