{"id":2278,"date":"2018-08-14T22:34:16","date_gmt":"2018-08-14T21:34:16","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=2278"},"modified":"2018-08-20T08:35:31","modified_gmt":"2018-08-20T07:35:31","slug":"bounded-contexts-in-the-wikimedia-fundraising-software","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2018\/08\/14\/bounded-contexts-in-the-wikimedia-fundraising-software\/","title":{"rendered":"Bounded Contexts in the Wikimedia Fundraising Software"},"content":{"rendered":"

In this follow-up to rewriting the Wikimedia Deutschland fundraising<\/a> I tell the story of how we reorganized our codebases along the lines of the DDD strategic pattern Bounded Contexts.<\/p>\n

In 2016 the FUN team at Wikimedia Deutschland<\/a> rewrote the Wikimedia Deutschland fundraising application. This new codebase uses The Clean Architecture<\/a> and near the end of the rewrite got reorganized partially towards Bounded Contexts<\/a>. After adding many new features to the application in 2017, we reorganized further towards Bounded Contexts, this time also including our other fundraising applications. In this post I explain the questions we had and which decisions we ended up making. I also link to the relevant code so you have real world examples of using both The Clean Architecture and Bounded Contexts.<\/p>\n

This post is a good primer to my Clean Architecture + Bounded Contexts<\/a> post, which describes the structure and architecture rules we now have in detail.<\/p>\n

Our initial rewrite<\/h2>\n

Back in 2014, we had two codebases, each in their own git repository and not using code from the other. The first one being a user facing PHP web-app that allows people to make donations and apply for memberships, called FundraisingFrontend<\/a>. The “frontend” here stands for “user facing”. This is the application that we rewrote in 2016. The second codebase mainly contains the Fundraising Operations Center, a PHP web-app used by the fundraising staff to moderate and analyze donations and membership applications. This second codebase also contains some scripts to do exports of the data for communication with third-party systems.<\/p>\n

Both the FundraisingFrontend and Fundraising Operations Center (FOC) used the same MySQL database. They each accessed this database in their own way, using PDO, Doctrine or SQL directly. In 2015 we created a Fundraising Store<\/a> component based on Doctrine<\/a>, to be used by both applications. Because we rewrote the FundraisingFrontend, all data access code there now uses this component. The FOC codebase we have been gradually migrating away from random SQL or PDO in its logic to also using this component, a process that is still ongoing.<\/p>\n

Hence as we started with our rewrite of the\u00a0FundraisingFrontend in 2016, we had 3 sets of code: FundraisingFrontend, FOC and Fundraising Store. After our rewrite the picture still looked largely the same. What we had done was turning FundraisingFrontend from a big ball of mud into a well designed application with proper architecture and separation of subdomains using Bounded Contexts. So while there where multiple components within the FundraisingFrontend, it was still all in one codebase \/ git repository. (Except for several small PHP libraries, but they are not relevant here.)<\/p>\n

Need for reorganization<\/h2>\n

During 2017 we did a bunch of work on the FOC application and associated export script, all the while doing gradual refactoring towards sanity. While refactoring we found ourself implementing things such as a DonationRepository, things that already existed in the Bounded Contexts part of the FundraisingFrontend codebase. We realized that at least the subset of the FOC application that does moderation is part of the same subdomains that we created those Bounded Contexts for.<\/p>\n

The inability to use these Bounded Contexts in the FOC app was forcing us to do double work by creating a second implementation of perfectly good code we already had. This also forced us to pay a lot of extra attention to avoid inconsistencies.\u00a0 For instance, we ran into issues with the FOC app persisting Donations in a state deemed invalid by the donations Bounded Context.<\/p>\n

To address these issues we decided to share the Bounded Contexts that we created during the 2016 rewrite with all relevant applications.<\/p>\n

Sharing our Bounded Contexts<\/h2>\n

We considered several approaches to sharing our Bounded Contexts between our applications. The first approach we considered was having a dedicated git repository per BC. To do this we would need to answer what exactly would go into this repository and what would stay behind. We where concerned that for many changes we’d need to touch both the BC git repo and the application git repo, which requires more work and coordination than being able to make a change in a single repository. This lead us to consider options such as putting all BCs together into a single repo, to minimize this cost, or to simply put all code (BCs and applications) into a single huge repository.<\/p>\n

We ended up going with one repo per BC, though started with a single BC to see how well this approach would work before committing to it. With this approach we still faced the question of what exactly should go into the BC repo. Should that just be the UseCases and their dependencies, or also the presentation layer code that uses the UseCases? We decided to leave the presentation layer code in the application repositories, to avoid extra (heavy) dependencies in the BC repo and because the UseCases provide a nice interface to the BC. Following this approach it is easy to tell if code belongs in the BC repo or not: if it binds to the domain model, it belongs in the BC repo.<\/p>\n

These are the Bounded Context git repositories:<\/p>\n