Crafted Design

Sandro Mancuso@sandromancusohttp://leanpub.com/socra

What is this application about? What are the main concepts?

What does this application do? What are the main features?

Where do I need to change? Where do I put a new feature?

Looking from above, I can’t see what the application does or is about

Architectural and design concepts mixed with domain

Badly structured packages/namespaces

I don’t know where to start Classes and methods are too low level

Example: Layered structure

What does this application do? What is it about?

Example: Layered-domain structure

Books and Users. Cool, but what does this application do?

Example: MVC structure

Awesome. It’s a web application. So?

MVC & MVC Variations

• MVC (Smalltalk 76/80)• MVC (general concept – 1988)• Three-Tier Architecture (Presentation, Logic, Data)• MVC (Model 1/Model 2)• Model View Adapter (MVA)• Model View Presenter (MVP)• Model View ViewModel (MVVM)• Presentation-Abstraction-Control (PAC)• ….

MVC used badly

Anaemic Domain

Fat Controllers

Coupling with MVC framework

MVC & MVC Variations

They are all wrong. But they are also right. It all depends on the ‘V’iew.

Views impact MVC structureDepending on the view technology, Views and Controllers

responsibility becomes more/less coupled or blurred.

Web applications Single-page AJAX applications with stateless backend Console-based applications Desktop applications Games Mobile / tablets External systems (talking via Queues / Webservices)

However, the model should remain unchanged.

MVC – A Macro Organisational Pattern

Model

V C M

?

DeliveryMechanism

“Model” is overloaded and confusing

Model (M in MVC) Domain Model (DDD) View Model Data Model Entities & Active Record

and other artificial definitions from MVC frameworks

Associated with the persistence mechanism?

M => Domain Model (DDD)

Domain Model combines state and behaviour, with more focus on the latter.

DDD define a few building blocks to your domain:

Entities Value Objects Factories Repositories

Services Application Domain Infrastructure

Aggregates

<< Web app >>

Embedded Domain Model

ModelV C DM

DeliveryMechanism

Infrastructure Infrastructure

DBQueue

Deployable Domain Model

DeliveryMechanisms

<< external system >>

<< mobile app >>

DB

<< deployable app >>

Model

Infrastructure

DM<<W/S>>

<<W/S>>

Event-Driven Domain Model

DeliveryMechanisms DB

Queue

<< external app 2 >>

<< external app 1 >> << deployable app >>

Model

Infrastructure

DMQueue

<<event 1>>

<<event 2>>

Domain Model – Responsibilities

UC = Use Case, DS = Domain Service, S = Infra. Service, R = Repository

Model

UC 1

R 3

DS 1

DS 3

R 1

S

Infrastructure Impl

DM

DS 2

Impl

UC 2

<< web app >>

Repositories (not DAOs)

Model

<<repository>>

Library

<<repository>>

Users

Infrastructure<<Mongo>>

Books

Domain Model

<<Oracle>>

Users

“A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability.”

~ Eric Evans

Command & Query Use Cases

<< web app >>

Model

RDS

<<Write Model>>

UC

Model

<<Read Model>>

UC

DB

DB

Queue <<domain events>>

So, how does the app structure look like?

Web project responsibility

Control flow (invoke use cases)

JSON / XML parsers or converters

Page Objects, validators, etc

Static files

Core responsibility (simple project)

Tells what the system is about

Tells what the system does

Core responsibility (bigger project)

Epic / Theme

Epic / Theme

Epic / Theme

Related domain concepts

What is inside model packages?

Aggregate root (entity)

Repository

Entity (part of Book aggregate)

Domain Service

Value Object (part of Book aggregate)Part of aggregate behaviour

Repository

Value Object (part of User aggregate)

Aggregate root (entity)

Domain Service

What is inside infrastructure?

Interfaces defined by the domain.Dependency Inversion Principle (DIP)

CreditCardProcessor implementations

Repository implementations

Domain Model collaborations guideline

C

UC 1

UC 2

DS 1

DS 3

DS 2

R 3

R 1

cl

cl

cl

cl

C = Controller, UC = Use Case, DS = Domain Service, R = Repository, cl = class

Class responsibility

C UC DS R

cl

DB

Input Output

End of code branch

Produces the outputEnd of flow

First to handle inputStart of the flow

Execution Flow

Closer to the input: Control flow, higher level abstraction, detailed work is delegated (e.g. ProcessTrade (UC), MakePayment (UC)) — More suitable for Outside-In TDD (mockist).

Closer to the output / end of branch: Specific and detailed behaviour, no delegation, lower level abstraction (e.g. Parse XML (Parser), Create User (Repository))

Domain Model entry point Domain Concept

entry point

Defining testing strategies and boundaries

• Unit• Integration• Acceptance• Journey• Black box• Component• System• Functional• Alpha• Beta• Conformance• …

Types of tests

?

Testing strategies: User Journey

Model

UC 1

DM

UC 2

<< web app >>UC 1

UC 2

Tests the journey a user will have to do something useful in the system

Application is tested as a black box normally using a BDD framework

Use cases are facked. We just want to know if the application presents the user with the correct journey

Designed according to User Stories and Features

<<fake>>

<<fake>>

Infrastructure Impl

Testing strategies: Acceptance (Action / Behavioural)

UC DS 1

<<mock>>

RDS 2 R

Tests a behaviour (action) provided by the system

Use Case is the entry point and all external dependencies are stubbed

Domain Model

Normally tested using a BDD framework

Testing strategies: IntegrationTests the classes at the system boundaries

Infrastructure Impl

UC DS 1

<<mock>>

RDS 2 R

Domain Model

Normally done using an in-memory Database using a unit testing framework

Testing strategies: Unit (Class level)Unit test at class/method level

Infrastructure Impl

UC DS 1

RRDS 2

Domain Model

DS 1

DS 2All collaborators are mocked / stubbed (spies)

Testing strategies: End-to-End

Model

UC 1

R 3

DS 1

DS 3

R 1

S

Infrastructure Impl

DM

DS 2

Impl

UC 2

<< web app >>

Full application deployed

Uses BDD framework, accessing a testing database and fake external dependencies

Very few tests at this level, just to make sure application is wired properly

Outside-In vs. Classic TDD

The closer to the input a class is, the more flow control and delegation it does. The closer to the output a class is, the more specific and less delegation it does.

Using Outside-in TDD starting from Controllers and/or Use Cases.

Model

UC 1

R 3

DS 1

DS 3

R 1

S

Infrastructure Impl

DM

DS 2

Impl

UC 2

<< web app >>

Answering the two original questions What is the application about? (main concepts)

What does the application do? (main features)

Expressed by nouns

Expressed by verbs(Actions)

Thank You

http://leanpub.com/socra

@sandromancuso