I think that's a great description of the process. I would make the point that designing on customer language in OOP is one of those things experienced programm

I think that's a great description of the process. I would make the point that designing on customer language in OOP is one of those things experienced programmers shy away from. The next paragraph about "What to do, when" is a much better source of OOP design. Just to take the example of account balance, in looking at business-type worries it would probably become clear that transactional integrity is a big deal in this kind of software, so you'd want to clearly separate out queries on the balance and modifications to the balance and restrict access to the functions. These sorts of pressures, along with technical pressures much more clearly describe the design parameters.