The Intersection of Architecture and Implementation - Mark Richards - DDD Europe

The speaker begins the talk at the intersection of architecture and implementation with a story about a business needing an architecture to support a large number of users. The architect proposes a solution, but during development, questions arise about asynchronous communication and persistence frameworks. The architect's typical responses are that these are 'implementation details.' Problems occur when users are added, leading to errors and system failure, demonstrating a misalignment between architecture and implementation.

The speaker outlines the session's goal to address the misalignment between architecture and implementation. They will discuss operational, structural, and constraints alignment as roads to travel. Operational alignment involves how a system performs under load and its reliability. A scenario is described where an architect makes decisions based on scalability needs, choosing a microservices architecture that backfires when scaled due to an implementation misalignment focusing on performance.

The speaker moves on to structural alignment, using a house as a metaphor for logical architecture. Just as a house consists of rooms with different functions, software systems consist of logical components forming its architecture. Developers create code meant to reflect this structure, but often the implementation does not match the intended architecture, leading to systems that are hard to maintain and understand, illustrated by a software version's misalignment with its architectural plan.

The third road, constraints alignment, is introduced with a scenario emphasizing the importance of adherence to constraints for achieving the desired architecture. The speaker describes a common misalignment where the architecture focuses on isolating technical layers for changeability, while the implementation prioritizes performance, ignoring these constraints. This results in a system unfit for handling change efficiently, as database changes are prolonged due to the violated architectural guidelines.

Governance through architectural fitness functions is proposed as a solution, offering objective ways to test architectural characteristics. Using tools that report metrics for alignment ensures operational concerns are continuously met. The speaker explains how analytics services can monitor performance metrics to determine alignment with expectations, demonstrating a scalable system with real-time data analysis, showcasing the efficacy of fitness functions in maintaining operational alignment.

The discussion on applying fitness functions extends to structural alignment, using tools to test code structure against architectural plans. Several tools are introduced that help ensure code's logical architecture aligns with the design. Example tests are described to help maintain the alignment, such as ensuring code components reside in the correct package. This helps in maintaining the structural coherence of the system, preventing deviations from the intended architectural design.

The speaker continues with constraints alignment, showing how the same tools can ensure the implementation adheres to architectural constraints. Tests can be written to ensure, for example, that certain layers within the architecture only interact in prescribed ways. This approach enforces the architectural plan, thereby maintaining the design integrity by ensuring compliance with set constraints, which mitigates issues arising from unapproved shortcut implementations.

While governance can identify misalignments, it's ultimately pointed out that the root problem is lack of communication and collaboration between architects and developers. The speaker emphasizes the need for filling the 'chasm' between architecture and implementation to foster a bidirectional flow of information. This requires architects to be part of the same teams as developers, ensuring adjustments are communicated effectively, facilitating mentorship and leadership opportunities.

To improve collaboration, two golden rules are presented: explaining the 'why' behind decisions to developers and involving them in decision-making. If developers understand the rationale and participate in decisions, they're more likely to adhere to them. The speaker highlights the importance of architecture decision records (ADRs) as a tool for documenting decisions, their justification, and expected consequences, serving both informational and collaborative purposes.

The speaker expands on how ADRs are used, promoting their temporary use for communication rather than documentation. They suggest ways to introduce ADRs gradually, focusing on leveraging them for major decisions and using them to invite feedback from developers ('request for comment' status). This approach improves engagement and builds trust, allowing developers to challenge and contribute to architectural decisions, leading to better alignment and calmer, collaborative environments.