I want to program a simple budget application. In my application, the budget is divided into budget periods (months by default, but it can be bi-weekly or weekly periods). In each period there is a list of spending categories.

The user can perform different action on a category, like to record a spending, allocate budget, create new category, close existing category etc. So each category should have a different state for each period, but the changes for particular state of specific period should influence the category state of consecutive period (any change in spending/budgeting in January should change the state of a category in February). So each period should have a specific state of category that is belong to him and he can operate on, but the category itself should be able to see the changes that are made and perform changes in other states.

Initially I was thinking to implement a category as a list of its states, but my gut telling me that it's not a good design. I would really like to hear if there is a better design/design patter that can be used here.

From a high level point of view, it seems that you're searching for the observer pattern. You can turn your States into observables, and your Categories into observers (assuming you have abstractions for both your States and Categories). This way, whenever you create a new category, you can make it observe the already existing states, so that when they update, they can warn their observers to do so as well.

  • Ok, but how does this address the problem of the state related to the period for a category ? – Christophe Nov 23 at 18:23

According to your narrative:

  • Budget is decomposed in Period which have several Category
  • The user experience is Category centric, and the same Category is used across several Period.

This means that there is an many-to-many association between Period and Category. In an RDBMS, you would typically map this with an association table. You could add additional properties to such association using an association class. In the RDBMS mapping, these properties would then be additional columns of the association table.

And this is exactly what you want: to have an association between Period and Category and an association class (let's call it CategoryPeriod) that represents the state that corresponds to the occurence of that association (e.g. Category "Rent" for Period 2018-11 has budget_amount of $500). The state of the CategoryPeriod is the state you are looking for.

Now, you guess right: having these states as a list in Category is not ideal, unless it is sorted. I'd rather go for a map<Period>. If you go for a DDD design, you could also have the CategoryRepository implement a method to get a specific CategoryPeriod or a set of several items for the same Category.

Now for the impact of an update of CategoryRepository for period n, the easiest is to implement this operation via the Category aggregate root, and trigger the update of all the items for subsequent periods in the same category.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.