Mark van Venrooij

Mark van Venrooij's blog

Category: featured (page 1 of 3)

Continuing Domain Driven Design

tl;dr

In this post I continue my progress towards an DDD version of my favorite pet project. In this iteration I add a way to check the budget against the real expenses. The code is on GitHub and the picture contains the new model.

Continuing Domain-Driven Design

In my previous blog post I started to apply Domain-Driven Design to my favorite learning project. The quick summary of that post is that I started to create a Ubiquitous language and designed two aggregates.

Checking the budget

The main goal for the application is to check my expenditures against a budget for a certain category. To quote (a part of) the ubiquitous language:

To achieve financial insight the application needs to import and categorize financial transactions. I want to set budgets for a year and compare them to the actual amounts.

In order to check if my expenditures are still on budget I like to execute a method on Budget like budget.remaining(). To easiest way to calclulate the budget.remaining() is to substract the amount used for a budget from the amount planned.

To implement this method I need information that is stored in two aggregates. The actual expenditures are stored in the Category aggregate and the budget amount in Budget. I found several ways to implement the method:

  • Add the category repository to the budget aggregate.
  • Rethink the aggregate boundaries.
  • Make an application service to coordinate.
  • Make a domain service that calls the repository from the budget.
  • Using eventual consistency in combination with domain events.

Add the category repository to the budget aggregate

I can add the category repository to Budget, however this seems mixing responsibilities. Of course it will work. If I look at the internet this seems bad practice.

Rethink the aggregate boundaries

It is also possible to rethink my original design of aggregates. I could make budget the aggregate root that includes category and thus the transactions. This would make it easy to calculate the budget remaining. However Budget and Category have a different life cycle. A Budget is bound to a specific year while a Category typically will live for many years. Therefore this option is not the right one.

Application service to coordinate everything and do the calculation

I can create an application service that will coordinate the change and let it update both the category and the budget. In my opinion that sounds too much like procedural coding and is not a viable option.

Make a domain service that calls the repository from the budget

Another option is using a domain service that indirectly calls the repository. Linking the domain service in the entity is allowed. Although this seems actually not really different from including the repository, just another indirection. Therefore not an option for me.

Using eventual consistency in combination with domain events

The final option is raising an event every time a transaction is added. A separate event listener can then update the budget. This way I realize separation of concerns. The downside: some “infrastructure” is needed before it actually works. This is for me the cleanest option and thus the way forward.

However in this option there are some extra things to think about. A category spans multiple years and a budget is specific for a single year. So the question is which budget needs updating. There are several options for solving this.

  1. Loop through all yearly budgets for a specific category and update all budgets based on the new amount.
  2. Make the event specific for a year.

For now I have chosen for the option to loop through budgets for a specific category. Mainly because this is easiest to implement. Otherwise I need to compose a complex event that is targeted to update budgets including at least the transaction year or worse the whole transaction. That feels like mixing the aggregates a bit. Next to that by making the event more generic it is easier to reuse later if that is needed. By choosing this approach the consequence is that performance will take a hit.

Work to be done

Currently only the field amount is stored in budget. So now I need to change amount into amountPlanned and introduce amountUsed. Furthermore I need to create an AmountUsedUpdater that acts as an event listener to update the amountUsed. I didn’t use amountSpent because I have also some budgets for my income.

Conclusion

In this blog post I show the way I implement the comparison between the budget and the actual expenditures. The code is on GitHub. The picture below shows the domain model.

Domain-Driven Design model

The new model

quick update

A long overdue update from my side. As mentioned in previous post I got married last year. Next to that this year we welcomed a newborn daughter. So my life changed a lot the last 12 months.

Update on my path to financial independence

We saved a bit less than the goal (25%) of last year, this is basically due to buying a nursery and all other things for my daughter. However having a young daughter compensates for that a easily. The Savings as percentage of FI goal basically hit the goal as the stock market was pretty good. Ignoring any market changes and interest it would take approximately 36 years to be financial independent giving the total savings of last year. The goals for this year are a bit more modest compared to last year. It should be possible to reach the 20% savings rate and that would result in reaching 18% of my set FI goal.

Savings rate 2016

Savings rate year 18.5%
Savings as percentage of FI goal 14
years till financial independence using total amount of savings of last 12 months 36

Financial goals 2017

Savings rate 20%
Savings as percentage of FI goal 18%

Naive Bayesian Classifier on transactions

For a long time I have the idea to enhance my BudgetApp application with machine learning techniques. I would like to use these techniques to categorize my transactions. Let me first explain how my current solution works. I have a set of rules that are used to assign a category to a transaction. In principle there are two kind of rules: Rules based on the description of a transaction and rules based on the contra account number of the transaction. The first rule that matches the transaction is used to categorize the transaction. The rules engine works quite well. About 90% of all transactions are recurring so these can be categorized automatically. But on the moment you get a new kind of transaction that will be recurring you have to create a new rule so in the near future this will be categorized automatically. My total ruleset now contains about 100 rules. In a few years I collected about 1400 transactions that are categorized with the above mechanism. After trying a implementation of the K-nearest-neighbor algorithm. I finally use a bayesian classifier implementation which works quite well.

So 2 weeks ago I finally decided to try using machine learning techniques. With all the categorized transactions I have a great set of data that I can use for supervised learning, also this can be used to validate my solution. There are a few basic assumptions for my solution. I don’t mind that the chosen solution is not able to classify a transaction but it should have very little incorrect classifications. The tool is used to create a budget and if too many transactions are incorrectly classified, the budget might be incorrect.

One of the easiest classification algoritms to implement is K nearest neigbour. The algoritm might be slow if you have many data points. But my total data set seems to be small (only 1400 entries). The main part of this algorithm is to construct a distance function that determines how similar the new transaction to categorize is compared to all other transactions. Looking at the previous solution I recon that there are two major features of a transaction that are used to categorize a transaction: Description and Contra account. So probably the distance function should use these two things to categorize a transaction. I think that the contra account is a good place to start. Basically each different contra account should indicate another category. While running this on the real data I notice that I got a lot of incorrect categorizations in my set, and more importantly that it takes a few minutes to calculate the category of 10 transactions based on the ‘learned’ input of about 1000 transactions. So the solution is actually pretty slow even on my small data set. Another problem I have is that I can’t think of a way to construct a description distance function. I don’t find it acceptable that a categorization of a dozen transactions takes minutes as the old way only takes seconds. After checking if I could improve my calculations I found I didn’t make any major mistakes. Now I have an extra requirement: the solution should be about as fast as the rules solution.

Back to the drawing board it is. I need to select a different classification algoritm. After spending some time on the wikipedia pages I think a naive bayesian classifier might help me. It is pretty straightforward to implement. Furthermore it seems to be quite effective and efficient for similar problems (like spam filtering). A naive bayesian classifier assumes that an absence or presence of a feature is independent of the presence or absence of another feature. This assumption is often wrong, but in practice it seems to work pretty well. Let’s implement this thing.

Starting with the contra account number. What is the probability that a new transaction has contra account 123 and belongs to category x? I think it should be the number of transactions with contra account 123 and category x in the training set divided by the number of all transactions with contra account 123 I can’t think of a better way to find the probabilities on this feature. After implementing this thing I use about 10% of all known transactions as training set and try to categorize the remaining transactions to validate my solution. The results are really promising: 533 transactions are categorized correctly, 697 couldn’t be categorized based on the contra account number (basically the contra account number for these transactions is zero or not in my training set), and only 11 transactions are classified incorrectly. After some investigation on these incorrect transactions I notice that 10 of them fall in the category “salary” while it should be “expense claim”. As my probability only takes the account number as feature this makes sense. I have far more salary payments than expense claim payments. This problem should be resolved if I add more features to my probability calculations. Probably if I add description the distinction can be made. I might include the transaction amount as well as these amounts are quite far apart.

Implementing the probability of the descriptions is similar to the contra account number: the number of transactions with word y in the description and category x in the training set divided by the number of all transactions with word y in the description. This works only for a single word in the description. To combine multiple words these probabilities should be multiplied. Ok implemented, time to validate again: 912 transaction classified successfully, 208 can’t be classified and 121 classified incorrectly. The incorrect classifications worry me. If I look into the details I see that most of them are classified as groceries but the actual category can be many things e.g. gifts. The problem here is that most incorrect transactions are “pin” transactions as we call that in the Netherlands, transactions paid with my debit card. The transactions are categorized as groceries due to similarities in the description field. They all contain the same words.

At this moment the solution cannot replace the ruleset mainly due to the high number of incorrect classifications. However I want to include other features as well. The amount should fix some problems.

P.S. As a proof that the old system is not ideal as well I found 1 transaction that was incorrectly classified in the old system!

Leaky abstractions in JPA eclipselink

Leaky abstractions in JPA/Eclipselink

Leaky abstractions in JPA/EclipseLink

In our team we use JPA, EclipseLink to be precise. Now we start stress testing we notice something weird. The child relations of a entity are not updated if we only save the child. Probably we can prevent it by some configuration/annotation or other way, but we use an ORM to make sure we don’t have to think about these things.

Let me give you some code samples. There are two entities involved: ParentEntity and ChildEntity:

Furthermore we have a ParentEntityRepository object manages access to the entities.

Some times we need to add a new child to an existing parent. The easiest way to do that is to create a child set the parent and save the child.

The problem now is that the new child is not added to the parent in our front-end, but in the database the child is added and has the correct parent attached to it. After some time (EclipseLink cache expiration?) the results are correct.

I think this is really disturbing. You use a ORM to have an abstraction from your data layer, but it seams it’s a leaky one. I can’t remember that Hibernate has the same behavior, my memory might be misleading me though ;-).

P.S. The solution is to add the child to the parent and then save the parent, but I don’t think that should be the case.

Edit:
Coen Damen pointed me to the EclipseLink F.A.Q. with another solution by calling refresh() on the parent. Still I think it should be managed by the framework as I don’t want to think about database relations and when to refresh an entity.

Devnology codefest: Space Invaders quine

You saved the world - Invaders defeated

You saved the world

As a participant in Devnology Code Fest Space Invaders I knew immediately what the solution should be.

Some time ago I visited the Hot or Not Software Craftsmanship session by @KevlinHenney. In that session Kevlin introduced me to the principle of a quine and showed some examples. One of the examples was the Qlobe – a quine that shows a globe in the source code that rotates 45 degrees when executed.

So my contribution should be a space invaders quine. Furthermore my ruby skills need some practice so it will be a ruby space invaders quine. This is also a good excuse to finally finish reading Programming Ruby: The Pragmatic Programmers’ Guide. Below you a few possible game states are shown, the full solution can be found at GitHub.

Older posts

© 2018 Mark van Venrooij

Theme by Anders NorenUp ↑