• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Conceptual approach: financial software

 
Katrina Owen
Sheriff
Posts: 1367
18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am trying to determine a good way to structure an application that I want to build.

I have been struggling with this for some time, drawing faux-UML, crossing stuff out, drawing more faux-UML, uttering mild expletives, crossing more stuff out, etc. and I keep catching myself thinking: There has to be a pattern for this.

I am confused enough that I am pretty sure any explanation of the problem is going to be intolerably messy... here goes:

A person can have
- assets
- liabilities
- income streams
- expense accounts

Each of these are structured differently, and behave differently.

On the other hand, all of these have 'movements' which need to be tracked to specific dates, and I need to be able to generate various displays based on the movements.

These displays will generally be 'monthly', 'quarterly', or 'yearly'.
Or they will be breakdowns by account/category.

I seem to be able to structure my data so that either one or the other option is viable, but not both.

I guess my biggest problem is:
How do I structure the statement and movements so that I can get efficient displays of both separate accounts (breakdown) and overviews by period?

Does anyone have any suggestions as to how to approach this?

Best regards,
Katrina
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My advice would be to forget efficiency for now. Find a structure that makes sense from a behavioural point of view - what objects will have what responsibilities, and how they will need to collaborate.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You didn't show an entity for "movement" or transaction. I'd expect to see a collection of events that record a history or audit trail of what happened when. They might be very simple with fields for date, amount, from and to.

Once you have those, your displays might come very easily by iterating the collection and accumulating. I used to do a lot of this kind of thing:

That's assuming you want to do it all in memory. If you can create your displays from a database you can probably write a query to do most of the totals and breaks for you.

Does that seem to fit the problem?
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should also remind yourself to Apply Patterns Gently.

However Martin Fowler does discuss some recurring financial Analysis Patterns in his book Analysis Patterns: Reusable Object Models (amazon US)

6.12 Balance Sheet and Income Statement (Fig. 6.28)

UML Diagrams for Chapter 6 of Analysis Patterns (pdf)
Martin Fowler's Analysis Patterns articles
Martin Fowler's Accounting Analysis Patterns

However towards design and implementation you will still need to leverage considerable knowledge and insight into your particular business domain (as indicated in Domain Driven Design) - as the devil is often in the details.

Domain Driven Design � Tackling Complexity in the Heart of Software by Eric Evans
amazon US
Domain Driven Design Homepage
[ March 26, 2007: Message edited by: Peer Reynders ]
 
Katrina Owen
Sheriff
Posts: 1367
18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all for your suggestions and comments. This gives me a lot to chew on... the devil is indeed in the details!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic