The document describes a multi-team architecture used for two large distributed projects. For the first project, it utilized domain-driven design, CQRS, and message-based integration across 10 teams of 100 people developing multiple services and clients. For the second project, it used a single page application approach with independent sandboxed teams and module contracts rather than a shared codebase. Both aimed to allow isolated, faster teams through architectural patterns while coordinating features through contracts and integration.
2. Problem statement
Projects get bigger
Customers want shorter time-to-market
Distributed teams
𝑇𝑖𝑚𝑒 =
𝑆𝑐𝑜𝑝𝑒
𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑠
3. What is common
Complex behavior
Business logic isolation
Onion architecture
Client-side UI + WebAPI
Modular structure
4. Onion vs N-tier architecture
UITests
Business Logic
Data Access
Data Storage External Services
Infrastructure
Data Access
Business Logic
UI
Tests
Dependency Resolution
Business Logic
5. Key aspects of Onion Architecture
The application is built around an
independent object model
Inner layers define interfaces.
Outer layers implement interfaces
Direction of coupling is toward the
center
All application Business Logic
code can be compiled and run
separately from infrastructure
Dependency Resolution
Business Logic
7. Overview
Distributed system
4 months of active development
~8 windows services
~20 Web API services
Web application
2 mobile clients (android + iOS)
~10 teams
~100 people
8. Approaches and patterns used
DDD (Domain-Driven Design)
– Bounded Context = Windows (Domain) Service + Web API Services
– Ubiquitous language
– Services isolation and Clear responsibilities
CQRS (lite)
Message-based integration
– Commands
– Events
9. System architecture
Service Bus
Web API 1
Worker
Web API 2
DB
Web API 1
Worker
Web API 2
DB
Web API 1
Worker
Web API 2
DB
Service 1 Service 2 Service N
Web application iOS Application Android Application External Services
11. Process
Scrum
Each team has
– Developers
– Team Lead
– PM
– Scrum Board
– Backlog
Shared
– Product Owner
– Architects
– Test Team
– Core Team
14. Difficulties
No responsible person for technical contracts
– Single approach was not chosen
– Late issues and changes to contracts
Small core team
– Were not able to address all our requests
– We had to create some core-custom code
15. What was cool
Source code was available
– Helps greatly when investigating issues
Isolated subs-systems
Testable results
Internal Nuget server + packages
Continuous integration
Integration tests
17. Overview
Single application
Single Page Application
Teams - ?
People - ?
Modules - ?
Each team is sandbox
No system and source code available
18. Module4Module3Module2
System architecture
Web API
DB
Module 1
Web pages & scripts
Infrastructure Contracts
Contract
Business Logic
Module Contracts
NInjectModule
Infrastructure
DB
Contract
Infrastructure Functionality
Contract
Core Scripts
Host Engine
Mock Mock
SystemSandbox
20. Process
Scrum
Each team has
– Developers
– Team Lead
– Sub PO
– Scrum Board
– Backlog
– Test Engineers
– Architect
Shared
– Product Owners Board
– Core Architects
21. Difficulties
Small core team
Lack of documentation
No source code available
No system is available
Dependency on external components
Less understanding of infrastructure work
Lots of stubs are needed
22. What is cool
Very fast team setup
– 1 week knowledge transfer
– 1st
6-days sprint – one useful story is delivered
Less understanding of infrastructure work
Independent teams
Unit testing