Multi-Tier Application Architecture isn’t a new concept to anyone who has done any sort of enterprise development to the point nobody ask about this during technical interviews anymore.
At minimum, there’re always three basic tiers whether you’re building web application or client server application:
b. Application – Business logic
c. Data source
For financial applications, where do you put your calculations? That’s a matter of debate (but it shouldn’t).
I can’t tell you how many times I have seen applications gets built using the standard cookie cutter: DAO to load records from database into entities in Application tier, fashionably complying to every standard practice using OR mapper such as hibernate, Repositories and DAO with Spring and IoC container for every object. I’m not sure if people do this because they feel the need to comply with Golden OO design paradigm. Or too afraid to deviate from “Best Practice”. This pattern simply don’t apply to all scenario. Not just “edge cases”.
a. What kind of calculation are you running? Derivatives risk and pricing? VAR? Stressing? Time series analysis, covariance calculations, factor construction in portfolio optimization? Theses are computationally intensive. Quant libraries generally in c++, Python, Java. And typically load distributed and calculations, thus, done in “Application Tiers”.
Or are you running simple pnl updates, aggregate position level pnl/return/risk to book level? funding or trade allocation? Reconciliation? These are simple mathematics (no quant Library) : key concatenation/matching, simple aggregations. This brings us to next point.
b. Data volume, performance, and proximity to data source. If your calculations sources or operate on a lot of data, unless nature of calculation complex. Or that it requires quant libraries. There’s probably very little reason why these should be done in Application Tier. Databases are extremely good at keys concatenation /matching, aggregation and simple arithmetic. If data already in database, you’re processing more than a few thousand rows, performance gains can be realised by running these calculations in database/SQL BEFORE you move data from database tier to application tier. Even if you have multiple data sources (even message bus or non-SQL sources) : One can always build simple data feeds, consolidate into single database. Downside to this approach is, SQL not portable across different database vendors.
If calculations done in SQL, this means production trouble shooting can be done without a debugger. What this further means is that Level One support don’t need bother developers. More importantly, fixes can be simple SQL patches – no need recompile and redeploy, which adds to the risk.
d. Simplicity, Agile, and Maintainability
Let’s keep things simple. You’re adding complexity everytime you add a bean, entity, DAO – especially you have to maintain these mundane pieces of code manually. Imagine the amount of work you need to do if new fields need to be added? Worse if additions are to be performed on multiple entities/DAO (Although we no longer need updates hbm files anymore thanks very much). Speaking of which, #dotnet is full of Agile magic. Linq-to-SQL [completely] automates the process of generating entities & DAO: https://www.youtube.com/watch?v=bsncc8dYIgY
You don’t even need hand code the entities (Unlike Java/Hibernate). Linq-to-SQL, however, does not support updates. However, one can simply delete old entity/DAO files, then drag-drop to re-create the entities/DAO in seconds. This said, the achilles heel of Linq-to-SQL is: It supports Microsoft SQL Server only! (Ouch!!!)
#msdev are blessed with Linq-to-SQL. It doesn’t follow that Linq-to-SQL is the shortest path for all scenario. Most financial applications deals with data in Tabula format – #yesSQL!. And most financial calculations are simple additions/subtract and multiplications which can be done in SQL layer. Another Agile Magic that #dotnet has (And Java has not) is DataTable – there’s nothing simpler than loading a DataTable with a DataAdapter and bind to Grid on front-end. Example: http://www.dotnetperls.com/sqldataadapter
Many times, there’s just no real need for creation of entities just to comply with OO paradigm. Just because you don’t “bean” your reports and put them in nice little coffins mean it’s Dirty coding. In fact, by having fewer source files, your code is cleaner.
In fact, emphasis of Agile development should not be about Kanban board, stand-up meetings and micro-managing developers by incompetent or non-technical Project Managers (Titles should be more appropriately renamed to Project Administrative Assistance). Instead, emphasis and focus should be exploration and utilization of available Open Source and Commercial tooling that actually do actual work for you, and do things as simply as possible leveraging such technologies.
Don’t Over-Engineer and Happy Coding!
Oh… apparently last time someone think about this was back in 2010: http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/