How to Think Like a Programmer (Part Two)

In the previous part we introduced this blog series with the aim of helping developers that are new to the software engineering industry and highlight potential challenges that they may encounter as they begin their journey into this field. The next parts will focus on specific technical areas of software development. This part will cover how to model solutions using domain driven development.

I have a business problem, where do I start?

Start off with your domain

At university, you typically will be focused on learning the syntax for a particular language, or understanding key aspects of operating systems, or computational logic/math. The challenge when you get to industry is how to apply that theory in practice. Most likely, a lot of your time will be spent with users in your organization understanding what they do on a day-to-day basis and how software can improve their current functions, such as reducing the number of steps it takes to complete a process, improving the speed of certain processing and just making sure you have a complete understanding of the problem space before writing any lines of code. It is not uncommon for you as a software engineer to spend a significant amount of time trying to model your organization function into a process that can be automated through software. One methodology that you may find useful is Domain Driven Development.

Domain Driven Development is an industry design practice of modeling your software within the context a given domain, based on inputs from domain experts. This domain can be a business, it can be a particular functional area, or it can even be a particular product. Domain Driven Development lends itself very well to concepts such as object orientated programming, and if modeled correctly you will be able to explain to a non technical user how your software will work by explaining it in terms that relate to their domain.

In theory this all makes sense. So how do we apply this in reality? To showcase how we can do this we're going to walk through an example.

Example Problem Statement

In our workflow, data stewards are responsible for maintaining reference data. Data stewards have the capability to add, update, and delete reference data as appropriate. Data analysts on the other hand can only view reference data for research purposes. Our data stewards currently maintain two sets of reference data; Financial Products and Client Accounts. Financial products contain information such as International Securities Identification Number (ISIN), market code, GSN and take two main forms: Stock and Bonds. Stocks can be sold and bought from companies whereas a Bond can be issued by governments. A client account contains information such as account name, client id, and an is active status.

The above problem statement is a very simplified example of a problem that is often found in areas which deal with financial data management. As simple as it may appear to be, there is a significant amount of detail that can be gleaned. Our next objective is to turn this problem statement into a domain model. There are several ways that this can be done. One approach that I've often used is splitting my problem statement into three parts: Entities, Responsibilities, Associations.

Entities

When I encouter a problem statement like this is I first try to identify the individual entities that will make up the domain model. Based on the above problem statement, I've picked out the below entities. At this stage, I don't focus on what each entity will do; I'm just concerned with picking out the concepts that I think are needed in my domain to produce a model that can be turned into an automated software solution. 

• Reference data user
• Data steward
• Data analyst
• Product
• Account
• Stock
• Bond
• Owner
• Issuer
• Entitlement
• Responsibilities

Responsibilities

After identifying my entities I tend to think about the responsibilities of each entity. Responsibilities can be thought of as functions for an entity and define the rules that an entity needs to comply to. Based on the problem statement, I start to think about the responsibilities each entity will have. I often find modeling to be a very iterative process; typically when I drill into the responsibilities I find that there are other concepts that I need to model. If you look at the list now, there are a couple of other entities that I have identified that I didn't have originally. 

Below you will find my current set of entities with a brief a description of what they are responsible for.

• Reference data user - Someone who uses the reference data in some shape or form.
• Data steward - Data stewards appear to be a reference data user with add, update, and delete access.
• Data analyst - A reference user with only view access.
• Product - Based on the above problem statement. this a type of reference data that needs to be maintained. Products have the attributes ISIN, market code, and GSN.
• Account - The second type of reference data that needs to be maintained.
• Stock - A type of product.
• Bond - Another type of product.
• Owner - A representation of a company who can buy and sell the stock.
• Issuer - A representation of someone who can issue bonds.
• Entitlement - A representation of the type of entitlements.
• Reference data repository - A container for all the different types of reference data that needs to be maintained.

Associations

After listing out the responsibilities, I then start to think about how the different entities will interact with each other. There a several techniques that can be used here such as a flowchart, block diagrams or entity relationship diagram. Entity relationship diagrams were created for the purpose of modeling entities but I often use a UML (Unified Modeling Language) class diagram to do this. Sometimes using object oriented concepts to model your domain often can be a natural fit for explaining how the different entities that you have come up with interact with each other. In addition, UML also provides a good means for modeling entity behavior. In this blog, I use a UML class diagram to demonstrate how to highlight associations in my domain.