DDD N-Layered Architecture Guidance

WHY & NEEDS WHAT IS DDD?

improve

CQRS

CQRS

NEXT STEPS

Why & Needs

express objectives encapsulate with

What is DDD?
isolate domain with

NEXT STEPS
evolve towards

HOW?

DDD ARCHITECTURE PATTERNS

Our Foundations & DDD Architecture Patterns

Digging into Architecture Layers

Digging into each DDD Architecture Layers
Explore details

How?
Cesar de la Torre
Architect Evangelist Microsoft - DPE
" Blog: http://blogs.msdn.com/cesardelatorre * Email: cesardl@microsoft.com

Background & Needs

Customers are asking for Architecture patterns, and then, how to map it to Microsoft technologies Corporate & ISVs Architectures: Customers need pre-stablished corporate Architectures in order to have a single way of building enterprise apps. Something to be shared between several development groups. Need to show a global & clear way, for Software Architecture and Microsoft latest technologies relationship.

| Architecture

2010: A lot of .NET 4.0 Wave RTM news

ADO.NET Entity Framework V4.0

| Architecture

.NET 4.0 Wave news

ADO.NET Entity Framework V4.0

| Architecture

.NET 4.0 Wave news

Architecture

ADO.NET Entity Framework V4.0

| Architecture

.NET 4.0 Wave news

Architecture

ADO.NET Entity Framework V4.0 ADO.NET Entity Framework V4.0

| Architecture

N-Layer vs. N-Tier?

Logic Layers

Physical Tiers

They are additional!!..

| Architecture

How?
Elaborating a Reference Architecture Guide for Complex Enterprise Apps Mapping Architecture & Design patterns to .NET 4.0 technologies

| Architecture

Achitecture Guide Objectives

To Show latest architecture tendencies and patterns for Enterprise Applications How to map those patterns to our technologies To Provide a way to standarize enterprise & ISVs Software Architectures To Improve .NET platform adoption in complex enterprise scenarios

| Architecture

White Book

Guide/Book in Two Levels:

1.- Logic (Architecture & patterns) 2.- Implementation (Mapping to .NET 4.0 wave)

Sample Application (English)

Public at (OSS License)
Community Collaboration (Partners & MVPs)

| Architecture

Target Application type

Complex Enterprise Apps (Or ISVs products)
Areas: Finance, Telcom, ISVs, Retail, etc.

High Business/Domain Logic volume

Enterprise QoS requirements
Corporate Security (heterogeneus) High Performance & Scalability High Unit Testing volume Apps with a long evolving life

No RAD-apps in this context

| Architecture

Software Architecture site in MSDN-Spain Free download of the Architecture Guide

http://msdn.microsoft.com/es-es/architecture/default.aspx

| Architecture

Book-Guide: Domain Oriented NLayered Architectures with .NET 4.0

| Architecture

Sample Application at CODEPLEX

SampleApp & Codeplex-Site in English! http://microsoftnlayerapp.codeplex.com/

| Architecture

Sample Application based on our Domain Oriented NLayered Architectures with .NET 4.0 guide.

| Architecture

DDD is A Set of driving principles

Focus on the Core Domain Explore models in a creative collaboration of domain practitioners and software practitioners Speak an Ubiquitous Language within an explicitly Bounded Context

| Architecture

DDD: Project Lifecycle

- DDD is, overall, a way of working and facing a project - DDD working process is NOT covered by our Architecture Guide. We cover DDD Architectural Style.
Architecture & Design
(*) If you want to know DDD process, read Eric Evans book and many others. Martin Fowler is also focusing on DDD patterns

Improves Design & Architecture

Communication with

Domain Experts

Speeds-up a right development

Developers Feedback

Development

| Architecture

Why DDD? - When using DDD?

Complex Apps
Focus on Complex domains

High Domain/Business logic volume Domain knowledge No Data-Driven Apps

| Architecture

DDD is A Pattern Language

A set of interrelated problem/solution pairs that have helped teams realize the principles A vocabulary and conceptual framework for discussing domain modeling and design (Architects need to speak the same language, patterns names, etc.)

| Architecture

DDD Definitions

Domain: A sphere of knowledge, influence or activity.

| Architecture

DDD Definitions

Domain Model: A system of abstractions that describes selected aspects of a domain.

| Architecture

Domain Model

Same Domain different Models

| Architecture

DDD Definitions

Domain Model Helps us to solve specific problems in our Domain Is not necessarily realistic Forms the basics of a language Is not the only model

| Architecture

DDD Definitions

Ubiquitous Language: A language structured around the Domain model and used by all team members to conect all the activities of the team with the software.
It must be the same language used by the Domain Experts

| Architecture

DDD Definitions

Context: The setting in which a word or statement appears that determines its meaning

| Architecture

DDD Definitions

Bounded Context: An operational definition of where a particular model is well-defined and applicable (Typically a sub-system or the work owned by a particular team)

| Architecture

DDD: Domain Driven Design

Process & Project Lifecycle

- ALM, Agile processes - Dev-Team relationship with Domain experts (Business experts). - Ubiquitous Language

80%
| Architecture

20%
Building Blocks
(*) In our Architecture Guide we currently focus just on this area (20%)

Architecture

Our Architecture Foundation Pillars

Domain Oriented N-Layered Architecture SOLID: Base Design & Dev. principles

| Architecture

SOLID Principles in Development

Single Responsability Principle

A class must have a unique reason to be changed

Open Close Principle

A Class must be opened to extension but closed to changes

Liskov Substitution Principle

Sub-types or child classes must be substituted by their own related base types (Base class or Interface)

Interface Segregation Principle

Consumers must not be forced to implement interfaces that they are not using

Dependency Inversion Principle (*)

High level layers must not depend on low level layers. Both layers must depend upon abstractions

| Architecture

DDD Architecture Style tendencies

Some interesting DDD Architecture aspects & patterns

Isolate Domain Layer (Core)

This point perfectly fits with the Dependency Inversion Principle and DI

Decople all Infrastructure Layers from the Domain Layer! Specific Architecture & Design DDD artifacts (Layers & Patterns) ORMs help a lot
Entity-Framework, NHibernate, etc.
| Architecture

Original DDD patterns (By Eric Evans)

| Architecture

(*) Eric Evans diagram

DDD patterns
QUERY SPECIFICATIONS UNIT OF WORK

POCO / IPOCO

MVVM, MVC, MVP Patterns

CQRS

IoC IoC Containers CONTAINERS

| Architecture

(*) Eric Evans diagram

DDD Architecture (Eric Evans Diagram)

User Interface
Views Controllers

Tasks

Applciation

Application Services

Domain

Domain Entities

Domain Services

Infrastructure

CrossCutting Infrastructure
(Security, Logging, etc.)

CrossCutting Infrastructure
(Security, Logging, etc.)

Data Access & Persistence (Repositories etc.)

CrossCutting Infrastructure (3D Graph Libs, etc.)

| Architecture

N-Layered Domain Oriented Architecture (Simplified)

Crosscuting Infrastructure Layers (Security, Operations, Cache, etc.)

| Architecture

Presentation Layers Distributed Services

Application Layers Domain/Business Layers

Data Persistence/Access Layers)

Fuentes Datos

Servicios Externos

N-Layered Domain Oriented Architecture (Full version)

Cross-Cutting Infrastructure Layers
Rich Client / RIA

Web ASP.NET Client

UI Views
Controllers Svc Agents

UI Views
Controllers

Presentation

Distributed Interface Layer (Web-Services)

Application Layer

Tasks

App. Services

Use Case Drivers

Operations

Security

Cache

Domain Layer
Domain Services
Domain Entities

Workflows Query Specifications

Repositories Contracts

Bases (SuperTypes)

Infrastructure Layer for Data Persistence

Repositories
(Implementation) Persistence
(ORMs: EF, NHibernate)

Bases (Layer Supertype) Data Model Svc Agents

App Server Components

Data Sources

External Services

| Architecture

Layer diagram in VS.2010

Relation mapping to layers projects and .NET code We can even validate our Architecture diagram against actual .NET code in our solution!
| Architecture

Domain Model Layer

| Architecture

Domain Model Layer

- It is the Core of the Software. - Put in this Layer only what you would talk with a Domain Expert (Business user..). - It contains pure business/domain logic and entity model - It must not be contaminated by other layers and infrastructure components - It must be Persistence Ignorant, independent from Data Sources and even from Data Access technologies
| Architecture

N-Layer Architecture pattern

(*) Eric Evans diagram

| Architecture

Dependencies in DDD N-Layered Architectures

Domain Model Layer

The Domain Model is the Center

Most Dependencies must be based on ABSTRACTIONS/INTERFACES (Ideally using IoC & Depend.Injection) Swappable Implementations
| Architecture

ENTITY pattern

(*) Eric Evans diagram

| Architecture

Entity Classes situated within the Domain Model Layer

Entity Classes must be part of te Domain Model Layer I might want to swap the Data Access Layer with no impact to my Domain/Application Layers If using Entity Framework T4 templates, well need to move the Entities T4 template (POCO or STE) to the Domain Model Layer
Distributed Interface Layer (Web-Services)

Application Layer Domain Layer

Tasks

App. Services

Use Case Drivers

Domain Services
Domain Entities

Workflows Query Specifications

Repositories Contracts

Bases (SuperTypes)

Infrastructure Layer for Data Persistence

Repositories
(Implementation) Persistence
(ORMs: EF, NHibernate)

Bases (Layer Supertype) Data Model Svc Agents

App Server Components

| Architecture

Entity pattern
Object that has its own Identity It is characterized by itself (Identity), not by its attributes Attributes can change, but its identity is always the same Continuous Trazability in Time It has its own logic situated within the entity class
No Anemic Domain Model (MFowler)

Entity-Classes must be Persistence Ignorant POCO

Example: Person, Customer, Order

| Architecture

Transaction Script vs Domain Model

(*) Related to No Anemic Domain Models in DDD

| Architecture

[DEMO]
-Implementing the Entity pattern: - EF T4 templates (POCO or STE) - EF Code-First approach

| Architecture

Value-Object pattern

(*) Eric Evans diagram

| Architecture

Value-Object pattern
They have no Identity. They just describe things They are interchangeable, transitory They must be immutable.. When V-O or Entity? Depends on the Domain Model
Color Address Route between two cities

Example (Depending on Domain Model):

| Architecture

ENTITIES vs. VALUE-OBJECTS

Person Entity

Person Entity

Address VALUEOBJECT

| Architecture

[DEMO]
- Implementing Value-Object pattern:

| Architecture

Aggregate pattern

(*) Eric Evans diagram

| Architecture

Aggregate pattern

Related object-sets treated as a single unit.

Root Entity:
Responsible for validating consistency rules (invariants). It is the only entity within the aggregate that can be referenced from outside the Aggregate

Objects within an Aggregate can reference other root entities When we delete a root-entity we must delete the whole aggregate (cascade delete)

| Architecture

Aggregates

| Architecture

Aggregates & Repositories

| Architecture

Modules
They allow dividing a complex Domain Model in several simpler modules Divide and youll win Could be related to Domain Entity Models (1:1 or 1:many) We should seek for high internal cohesion and low coupling between several Modules Group by Domain concepts not by infrastructure/technical concepts Example:

Billing module CRM module HR module

| Architecture

Contexts and several approaches

Bounded Contexts (BC):

Model delimitation. We must create explicit boundaries at code level managed by each development team

Anticorruption Layer

Special Layer to isolate Bounded Contexts. It can provide translation artifacts between several models

Shared Kernel

Central sub-system (Kernel) shared by several Bounded-Contexts

| Architecture

[DEMO]
- Implementing Modules:

| Architecture

Domain Services
They are the backbone, the glue in order to coordinate all the domain rules and entities logic

| Architecture

[DEMO]
- Implementing Domain Services:

| Architecture

The Domain Model

It is the heart of the software.

| Architecture

Data Access and Persistence Infrastructure Layer

| Architecture

Repository pattern
QUERY SPECIFICATIONS UNIT OF WORK

POCO / IPOCO

| Architecture

(*) Eric Evans diagram

Nice to have
Having an ORM is much easier to implement the Repository and Unit of Work patterns. ORMs like:
Microsoft Entity-Framework NHibernate

| Architecture

ADO.NET Entity Framework Simplified Architecture

Whats different?
ORM & LINQ .NET Provider (EntitySQL)

V2.0

.NET Provider Store

| Architecture

Mapping

Conceptual Models Independent from RDBMS ORM Linq pattern for entities

Conceptual Model

Repository pattern vs. DAL (Data Access class)

DAL class

Works directly against a DB/Data source Does not provide an object oriented view of the data For a developer it is like a object collection Provides an object oriented view of the data Separation between the Domain Model and the data mapping Layer

Repository class

| Architecture

Aggregates & Repositories

| Architecture

Layer Supertype pattern: Reusing code

Implementing Repositories
Using Layer Supertype
It allows to create common methods for all your Repositories Very powerful when using GENERICS Inject dependencies in the constructor (like Icontext depend.)
| Architecture

Layer Supertype pattern: Reusing code

Implementing a Repository

| Architecture

[DEMO]
- Implementing Repositories:

| Architecture

The Application Layer

| Architecture

Unit of Work pattern

QUERY SPECIFICATIONS

UNIT OF WORK

POCO / IPOCO

| Architecture

(*) Extended Eric Evans diagram

The Application Layer

Put in this layer stuff & coordination you wouldnt talk with a Domain Expert Only plumbing coordination Example: Coordinating the use of UoW, Repositories or any other technical artifact. Those artifacts are infrastructure, so their implementation will be situated in Infrastructure Layers

| Architecture

[DEMO]
- Using UoW and Repository pattern from the Application Layer:

| Architecture

Distributed Services Layer

| Architecture

The Distributed Services Layer

- Very thin layer publishing your applayer and domain layer

| Architecture

Technologies for Distributed Services

- Base technologies
- ASP.NET Web-Services - (WS-I Basic Profile) - WCF (Windows Communication Foundation)
- Most specifications & standards (WS-I, WS-*, REST, HTTP, TCP, NamedPipes, MSMQ, etc.)

- Workflow-Services (WCF+WF)

-RAD (Rapid Application Development) NO DDD!!:

- WCF Data.Services (aka. ADO.NET DS) - WCF RIA Services (Relacin-Silverlight) - New! The King of RADs!! VS.Lightswitch
| Architecture

Data-items in N-Tier Apps: Possibilities

| Architecture

CustomerService
Service Contract / Interface

Customer Entity

Query Specification

Repository CustomerRepository
SuperType

Domain Entity

Query Specification (Contrat)

Repository Interface (Contract)

Methods including Domain Logic within the entitity classes!! No Anemic Domain Application Service Repository

Application Layer

| Architecture

Domain Layer

Data Persistence Infrastructure Layer

Presentation Layer

| Architecture

Presentation Layer
Main Presentation Layer pattners and when to use them:
MVC Web and ASP.NET MVC MVP WinForms MVVM WPF & Silverlight

| Architecture

Cross-Cutting Layers

| Architecture

Cross-cutting aspects & QoS

-Security
-Claims-based Security (WIF: Windows Identity Foundation, aka Geneva) - Authentication, Authorization, encryption & sign. - Windows Server AppFabric (WCF/WF Deployment and Cache (Velocity)

- Cache

-Exceptions Handling - Validations -Operations & Monitoring

-Performace Counters -Logging & Traces -WMI

- Globalization & Localization

| Architecture

Claims based Security, When traveling

Security Boundary

Check-in counter

Passenger

3. Boarding Pass Authorization at the Boarding Gate

Boarding Gate & Flight

Claims based Security Architecture

Security Boundary
Credentials Store

WS-Trust Issue() Initial Users Credentials

Tokens Granter
(STS: Security Token Service)

Security Token
Web-Service Or Web-App

Client App End-User and Client Application

Security Token

Application Server
(Relaying Party)

3. Token Authorization to access App resources

Architecture ADFS 2.0 & WIF

SQL Server Custom stores Security Boundary Active Directory (AD)
Active Directory Lightweight Directory Services (AD LDS)

Initial Users Credentials

WS-Trust Issue()

ADFS 2.0
(STS: Security Token Service)

Authentication

Attributes Extensibility (Claims)

SAML token Web-Service

Client App Client App and End User

SAML token

App-Server
WIF API (Relaying Party)

3. Token Authorization to access App resources

Deployment patterns
- Physical Architectures - N-Tier Architectures - Security in Tiers

| Architecture

(COMMAND AND QUERY RESPONSIBILITY SEGREGATION PATTERN)

Presentation

Reads Model

Writes Model

(Queries)

(Domain Model)

| Architecture

Slide 92

(COMMAND AND QUERY RESPONSIBILITY SEGREGATION PATTERN)

Search Products for Client Queries

Buy a product

Presentation

Commands

Reads Model (Queries)

Mensajes/Eventos Producto comprado

Writes Model (Domain Model)

| Architecture

Slide 93

Presentation
DTO Query
(sync.)

ack Command (Async) Domain Model Persistence Writes Store Transactional Store

Data Access Layer for Queries

Commands Handler

Query
(Sync)

Publish (Event/Message) (Async) Updates

Reads Store

Events Handler

| Architecture

Slide 94

Evolving to next versions

Points to be added in future Sample-App versions:
EF Code First approach + DTOs Convergence to Cloud-Computing CQRS Pattern (Command and Query Responsibility Segregation) Windows Azure implementation New Client apps ASP.NET MVC 3.0 Adding MEF and Silverlight 5.0 Client Windows Phone 7 (Silverlight) Security Claims Orientation (WIF + ADFS 2.0) in Windows Server (WIF + Access Control) in Windows Azure
| Architecture

Next Steps
1
Download SampleApp from CODEPLEX

2 Give us feed-back and feel free to collaborate!

Guide/Book English version. Feed-back!, almost releasing it!

| Architecture

Contact
http://microsoftnlayerapp.codeplex.com/
Csar de la Torre
Architect Evangelist Microsoft DPE

" Blog: http://blogs.msdn.com/cesardelatorre * Email: cesardl@microsoft.com

| Architecture