Multi Team Architecture

24
Multi-Team Architecture Maxim Kovtun Solution Architect

Transcript of Multi Team Architecture

Multi-Team Architecture

Maxim Kovtun

Solution Architect

Problem statement

Projects get bigger Customers want shorter time-to-market Distributed teams

What is common

Complex behavior Business logic isolation Onion architecture Client-side UI + WebAPI Modular structure

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

UI

Tests

Infra

struc

ture

External Services

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

UI

Tests

Infra

struc

ture

External Services

Project #1

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

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

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

Process

Scrum Each team has

– Developers– Team Lead– PM– Scrum Board– Backlog

Shared– Product Owner– Architects– Test Team– Core Team

Tools and Libraries

Gerrit – git-based code review tool Jenkins Nunit NHibernate Nuget server NServiceBus Jira Postman

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>

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

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

Project #2

Overview

Single application Single Page Application Teams - ? People - ? Modules - ? Each team is sandbox No system and source code available

Module4Module3Module2

System architecture

Web API

DB

Module 1

Web pages & scripts

Infrastructure Contracts

Contract

Business Logic

Module Contracts

NIn

ject

Mod

ule

Infrastructure

DB

Contract

Infrastructure Functionality

Contract

Core Scripts

Host Engine

Mock Mock

SystemSandbox

NInject code sample

Process

Scrum Each team has

– Developers– Team Lead– Sub PO– Scrum Board– Backlog– Test Engineers– Architect

Shared– Product Owners Board– Core Architects

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

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

Thank you!

Questions?