Don't know. that would be for you to decide. One possibility is simplifying the whole architecture by omitting parts. Add those parts back later. Work out which parts are dispensable and which indispensable. Maybe VIP status is dispensable and loan repayments are indispensable. Implement the dispensable parts after you have got the basics working.
Darko Jakimovski wrote:. . . What would be the second pass?
Yes. Make diagrams at all stages if you think they would help.
Is making a diagram of the architecture in the end good practice?
The diagrams should look straightforward. If you have lots of crossing arrows and lines, consider whether your diagram is right. If you can get rid of the crossings by moving one class, you have drawn that class in the wrong place Move it.
What's good and what's bad architecture?
What a nice thing to say
I'll ask you guys everything since I couldn't find good resources on the internet.
Darko Jakimovski wrote:I thought about that too, like have a parent Account class and Savings and Checking sub classes so I can put them in a Collection field in the Client class. Does that sound ok?
Darko Jakimovski wrote:. . . Enums will make the code more flexible . . . have a parent Account class and Savings and Checking sub classes so I can put them in a Collection field in the Client class. Does that sound ok?
This sends chills up my spine. A client needs a unique ID but in no way should that be related to a SSN. IF a system has SSNs then they should be encrypted. SSN's are not guaranteed to be unique, though most of the country treats them like they are.
Darko Jakimovski wrote:....client's SSN....
Carey Brown wrote: This sends chills up my spine. A client needs a unique ID but in no way should that be related to a SSN.
Darko Jakimovski wrote:Anyways all registered clients will have their client ID of course.
I wrote:this kind of approach more often than not leads to over-complex and over-engineered designs. ... traps you in a seemingly endless cycle of conjecture and pre-emptive design.
Darko Jakimovski wrote:So far I got most of the classes I'll need, fields for them. Now working on methods and Enums.
At this stage, I would go one further and write, “any number of accounts,” and change that to List or similar at a later stage of the process.
Junilu Lacar wrote:. . . prefer using List as the declared type instead of ArrayList. . . .