How to untangle bounded contexts after a team ownership reorganization?

Question

This is inspired by Eric Evans' presentation about bounded contexts when doing Domain driven design.

In his presentation he presents a case where a bank has initially 2 teams that manage 2 bounded contexts (Cash Accounts & Credit Accounts). As the business evolve the bank decides to have a reorg and now the focus will be on the Customer type mainly Business Accounts and Personal Accounts.

The problem is now each of the new teams need to work on both of the old already established bounded contexts which complicates feature development.

Eric doesn't explicitly address how to solve this problem and moves to a new example.

How do you propose as a solution to this entangled bounded context mess?

Answer 1

I assuming by team you mean some mix of bank staff (Tellers, Credit Risk Analysts, ...) not just the dev team working on the software.

Your question seems to be hinting at changing from 2 bounded contexts (focusing on cash & credit) to 2 bounded contexts focusing on Personal and Business accounts. Based on my limited knowledge of this domain, I think it is possible to immediately reject this idea. Just because the bank has re-organized it's staff, it doesn't change that fact that a Cash and Credit account probably have different functionality/requirements - if it made sense to have 2 contexts for this originally, it probably still does.

Given that the staff are transitioning to new roles/responsibilities within the bank, it is likely that you need to start a new requirements gathering process to understand the requirements for routing jobs/tasks to the relevant staff. Additionally you need to understand how future business and personal offerings differ. After you have collected the new requirements, you can decide what code you can re-use and what new functionality has to be developed.

A critical question that you need to answer is IF/WHEN/WHERE does it make sense to fork the existing bounded contexts. For example can the differences (between personal and business) be supported inside a single bounded context or would splitting it into two, make future development easier. Most likely the short term requirements can implemented fairly easily without splitting the context. Hence forking the context would only be necessary if/when continuing to support the business became too painful. It is probably better to plan ahead, so you can do any required splits when they are needed / most convenient.

It may also be too simplistic to split everything along business/personal lines, it could be that there is a core of credit transaction processing that is shared between business and personal accounts, but there are different requirements for approvals, so you might end up with 3 context, for example:

• Credit Transaction Processing
• Business Credit Approval.
• Personal Credit Approval.

Your requirements gathering will help you determine the best option.

Answer 2

The premise of Domain Driven Design is that if your let devs write software as they like, then you end up with odd restrictions on changes which align with the way the business thinks but not how the software is implemented.

The solution, implement the software in the way the business thinks.

However, if the business changes the way it thinks you still have the same problem. Theres no fix for this.

Practically speaking though you would hope even with a team reorg the underlying domain logic and operations would remain the same. You still have the two types of account and they still have the same rules. So there is no need to restructure the software to match the teams.

You might end up with legacy terms which would mean technical debt to refactor over time, but this will happen naturally in any case.