Exists a step-by-step process for buttom-up design from the beginning of the first line of code?

I'm searching for a kind of design patterns,idioms, concepts with the buttom-up design approach.

For example: I finished with the design and analysis cycle for a banking system. The requirements, features, uses cases and use diagramms etc. are ready made. (Top-down) Now for the implementation phase I'm switching to the buttom-up approach to code the first feature (after writing the unit-test).

Here is the main question: Exists articles, books, links about a step-by-step process like refactorings (Kent, Fowler etc) for buttom-up design from the beginning of the first line of code?

Something like a decision graph. Like implementing first variable -> method, functions, events etc. -> refactorings -> OO: first class, first object -> composition, inheritance, poly -> refactoring to patterns -> modules -> system, framework and so on.

I continue with the banking example to clarify it more: My first question in the decision graph asks me: 1. Do you need a variable, data?

    'Yes' - proceed to 2.

    'No' - proceed to 6. (Because DB exists already for example)

2. What kind of type has it to be?     'For my resource it is money and I use int, because I decided to compute it with cent-units (performance decision)' - Make it int-type and give domain depentend name!
3. Is it a global var?

'Yes' - Make it static

'No' - proceed to 4.

4. Is it fixed during lifetime?

'Yes' - Make it final and goto 6 (final can not be setted anymore)

'No' - proceed to 5.

5. Do you need a method, function to get/set this variable? 'Yes' - write this function (without validation at first) and give domain-depentent naming. 6... And so on....

Until I have the first variable and method, then it goes further to say that I should create the first class and refactor this var and method into it with the goal of OO-design. And every new step proceed further up in the decision tree until I have a 'Best practiced'-system. Best maintainable, extensiable, encapsulated, performant. All concepts involved from the beginning 'til the end. So you go more abstract until it fits the level of abstraction where you stop with top-down.

2. Second tiny question: Does so much duplicated code exists, because of abstract naming of variables, methods, classes? When I withdraw money from my bank account I simply do a mathematical routine - subtracting a variable from another (except for validation and security things etc)

Sorry for this looooong post, But thank you for reading