Building A Financial Website – Part 2 (Architectural Design)

It is very essential to have a mental picture of how the application will be structured and how the various components will interact with each other before proceeding to even write a single line of code. This point cannot be overemphasised especially in projects that involve other collaborators or programmers. If you are a lone wolf and with some experience, you might decide not to have such documentations since everything may already be crystal clear in your mind, but it still does not hurt to do if the project is of a considerable size, you never know when you may have to explain it to someone or look at your own code a couple of years from when you developed it and realise you may be lost in your codes, not to say it is a labyrinth or anything. The Architectural Design
Financials Architectural Design
High-level Architectural Design
In the context of this tutorial, a package is a collection of modules. The financial package will have the following modules
  • Shared – This will contain common codes that can be shared by the other modules in this package to avoid code duplication and ensure a common behaviour among the modules, where required.
  • Forex – Responsible for all things exchange rate related
  • Stock – Responsible for stock related information such as managing stock data of companies listed on a stock exchange (SE), managing indices of a SE, etc.
  • StockSimulator – Responsible for managing a stock simulator/ stock virtual portfolio to enable participants try out how the stock market works without taking any of the risks in the real market since real money is not used.

The Directory Structure

The directory structure for a module will follow these
  • commands – Scripts meant to be executed from the terminal and, as a result, can be scheduled to run automated tasks fetching data from external sources, sending notifications such as newsletters to subscribers, etc.
  • controllers – The C part of the Model-view-controller (MVC) architectural pattern
  • events – Contains event-related codes for inter-module communication where interested modules subscribe to the defined events and handle their own processing based on the fired/raised events
  • migrations – Scripts for creating/modifying
  • models – The M part of the MVC architectural pattern
  • services – Contains domain specific logic and acts as the only point of contact for this module.
  • views – The V part of the MVC architectural pattern
  • widgets – UI blocking blocks that can be used to compose an interface or a view for the user.
  • Module.php – Defines the module and can have codes to be run during the initialization of the module, i.e. during the bootstrap process. The name can be anything other than Module.php but we will stick to this for consistency.
The bold items are required for a module in this project while the italicized ones are not required so some modules may have some of them. What out for the next article in the series.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.