Quick recap
The team discussed the interface between the transfers bounded context and the accounts and balances bounded context, with a focus on the interface being 'chatty' and the potential benefits of combining accounts and balances and transfers in the same process. They also delved into the invariants Document, the significance of focusing on clear functional and non-functional requirements, and the role of a design authority in preserving the best possible design. Lastly, they explored potential changes to the reference architecture, the importance of design reviews, the introduction of versioning to the reference architecture, and the potential impact of refactoring existing knowledge on ongoing projects.
Next steps
- James will continue a discussion in the DA to address his concerns about the potential performance bottleneck due to the network interface between the transfers and accounts bounded contexts in the reference architecture.
- Sam will review the requirements and assumptions that led to the design of the reference architecture and provide clarity on them.
- Sam will investigate versioning the reference architecture to address ambiguity and ensure it remains a living document that can evolve with feedback and improvements.
Invariants Document Review and Revisions
The team discussed the invariants document and an open issue related to it. Paul confirmed that previous comments had resolved the final open issue, and the team agreed on the proposed changes to the document, with Paul leading the review. A point of confusion regarding the wording of a statement in the project documentation was also addressed, with James committing to reword it. Lastly, James indicated his intention to ask for a re-review on the DA channel, which was agreed upon by the team without objections.
Refining Reference Architecture and Separation
James raised concerns about the reference architecture, particularly the interface between the transfers BC and the accounts and balances BC being 'chatty' and suggested that the liquidity check should be clearly indicated on the flow diagram. He also proposed that separating accounts and balances from transfers across a network connection could introduce unnecessary overhead. Paul agreed, suggesting that accounts and balances could be a library used by the transfers BC. It was confirmed by James that in the upcoming implementation, accounts and balances will be separated and will run in separate docker containers in a Kubernetes cluster. The team agreed that while the reference architecture doesn't mandate separation, it also doesn't explicitly require integration.
Focusing on Clear Requirements in Design
Karim emphasized the significance of focusing on clear functional and non-functional requirements before design, and the role of a design authority as a custodian of the best possible design. Paul and James clarified that they were discussing a theoretical reference architecture, not implementation. They also differentiated between a reference architecture, which should fulfil all requirements before implementation, and an implementation, which involves detailed system design. The team agreed on the need for open discussions to keep the documentation current and a true reference for the system's design.
Forum Discussion on vNext Architecture
Julie encouraged taking a step back to examine the forum for discussing a particular document amidst high emotions. Paul agreed to initiate discussions despite not having all relevant parties present. Karim raised concerns about the existing reference architecture in vNext and suggested that any changes should begin with identifying issues or requirements not currently fulfilled by the design, such as performance or availability issues. Paul agreed with Karim's approach, emphasizing the importance of seeking input from the original designers.
Reference Architecture Change Discussion
Paul initiated a discussion about whether to change the reference architecture and the potential consequences of such a change. Simeon proposed postponing the conversation due to the tense atmosphere and the need for more involvement, particularly from Michael Richards. However, Paul disagreed, believing the discussion should continue due to its significance for ongoing projects. James clarified that he was not proposing any immediate changes, but the team needed a better understanding of his concerns. The group agreed to continue the discussion while also seeking a better understanding of James's perspective.
Discussing Reference Architecture Risks
James emphasized that a potential change to the reference architecture, while not a showstopper for the vNext project, should be discussed as a long-term risk. He highlighted the importance of design reviews in mitigating potential issues. Paul agreed and clarified that the current vNext implementation doesn't need to align perfectly with the reference architecture, but should strive towards it. The team agreed that open discussion of potential issues and risks is crucial for the success of the project.
Introducing Versioning to Reference Architecture
Sam proposed to introduce versioning to the reference architecture to reduce ambiguity and clarify that it's a living document continuously under improvement. He suggested that the current workstream could focus on reference architecture version 1.0, with ongoing efforts for version 2.0. He also emphasized the need to align the implementation with the reference architecture, but noted that exceptions could be addressed through a dedicated process. Lastly, Sam highlighted the necessity to document the requirements and assumptions underlying the reference architecture. Paul acknowledged Sam's suggestions.
Refactoring Knowledge and Managing Risks
Paul and Julie discussed the refactoring of existing knowledge and the potential impact on ongoing projects. Paul emphasized the importance of not delaying necessary discussions due to external factors, while Julie expressed concern about the potential impact on existing projects. There was also a discussion about the importance of maintaining a clean separation of concerns in the project's architecture, and the potential risks of chatty interfaces. James reiterated the foundation's commitment to delivering the highest quality software with the lowest possible risk profile, given the critical nature of the financial infrastructure it serves.
Bounded Context Transfer and Implementation Strategies
Karim and James discussed the potential issues and implementation strategies for the transfer bounded context and accounts and balances bounded context. Karim expressed concerns about maintaining two separate bounded contexts and suggested the need for implementation guidelines to ensure optimal design choices. James and Paul proposed a system where transfers, accounts, and balances are kept separate but functionally connected, with Paul suggesting a mitigation strategy of deploying the system on the same node or cluster. The team agreed to continue the discussion in the following week's meeting.
Please note that this content was originally generated by AI but has been reviewed for accuracy by James Bush. Some inaccuracies may remain. Please contact the author if you wish to make corrections.
Top comments (0)