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.

1. Multi-Team Architecture
Maxim Kovtun
Solution Architect

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

6. Project #1

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

10. CQRS
https://msdn.microsoft.com/en-us/library/jj591573.aspx

11. Process
 Scrum
 Each team has
– Developers
– Team Lead
– PM
– Scrum Board
– Backlog
 Shared
– Product Owner
– Architects
– Test Team
– Core Team

12. Tools and Libraries
 Gerrit – git-based code review tool
 Jenkins
 Nunit
 NHibernate
 Nuget server
 NServiceBus
 Jira
 Postman

13. System configuration
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id=“MyPlatform.Core" version=“1.0.0" />
<package id=“MyPlatform.SQLDataStorage" version=“1.0.0" />
<package id=“MyPlatform.Basket" version=“1.0.3" />
<package id=“MyPlatform.Catalog" version=“1.0.3" />
<package id=“MyPlatform.Payments.CreditCards" version=“1.0.6" />
<package id=“MyPlatform.Payments.Invoice" version=“1.0.0" />
<package id=“MyPlatform.ProductDetailsPage_BigImage" version=“1.0.0" />
</packages>

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

16. Project #2

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

19. NInject code sample

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

23. Useful links
 Domain-Driven Design
– http://www.pluralsight.com/courses/domain-driven-design-fundamentals
– https://msdn.microsoft.com/en-us/magazine/dd419654.aspx
 CQRS
– https://msdn.microsoft.com/en-us/library/dn568103.aspx
– https://msdn.microsoft.com/en-us/library/jj591573.aspx
– https://msdn.microsoft.com/en-us/library/dn589782.aspx

24. Thank you!
Questions?