Processes, patterns and architectures

http://epic.tesio.it/giacomo@tesio.it

P r o c e s sP r o c e s s

✔ Choose DDD✔ Find Domain Experts✔ Choose Modelers✔ Discover Contexts✔ Distill Languages✔ DevPool.Start(...)✔ Measure

C h o o s e D . D . D .C h o o s e D . D . D .✔ Cool? Just expensive!✔ Requires experience✔ For applications

business criticaloperativecomplex beyond tech

✔ Not for

data driven appsvendor-driven teams

W h o n e e d s a n E x p e r t ?W h o n e e d s a n E x p e r t ?

C h o o s e a M o d e l e rC h o o s e a M o d e l e r✔ Humble✔ Motivated✔ Smart✔ Fearless✔ Really skilled in OOP✔ Diligent✔ Comunicative✔ Responsible

(responsum abilem)

✔ Out of touch devs✔ Inexperienced devs✔ Technologists✔ Hackers✔ Unmotivated people✔ Sociopathics✔ Leaving company✔ Yielding people

D i s c o v e r t h e C o n t e x t sD i s c o v e r t h e C o n t e x t s

Creative Collaboration

✔ Identify the Core✔ Identify supporting

contexts✔ Name each context

think to namespaces✔ git add VISION.txt

(vision statement)✔ Look for dependencies✔ Schedule works

Domain Expert(Business Experience)

vs

Modeler(Development Needs)

Track Decisions!

D i s t i l l L a n g u a g e sD i s t i l l L a n g u a g e s✔ Bounded Context → Point of View / Language

✔ Context Name → Namespace (Project?)

✔ Distill Language → Write Contracts (POCO)

Entities, Value Objects, Services +Events & Exceptions (no checked exceptions in C#!)

✔ Share with clients → Look for questions (devs & archs) and feedbacks!!!

✔ Dwelve into (until the model is clear to the team)

OUTPUT CODE ! ! !(well documented)

ITE

RA

TE

! ! !

D e v Po o l . S t a r t ( . . . )D e v Po o l . S t a r t ( . . . )Once a Context is ready and known to the team, the related development tasks can START.

You can parallelize (with or without Epic):✔ Infrastructure (persistence, log, bus, cache...)

✔ User Interface (a good MVP framework can help here)

✔ Exposed Services (Soap / ReST / WCF...)

Meanwhile modelers can distill the next context.

M e a s u r e ( t o e s t i m a t e )M e a s u r e ( t o e s t i m a t e )✔ Customer feedbacks✔ # / € of Bugs✔ Modeling Effort✔ Development Effort✔ Breakthroughs✔ Refactorings✔ Parallelization issues✔ Reuse opportunities

Analyze Failures

to

Reduce Risks

Look For✔ Global Optimum✔ Explicitness/Precision✔ Shared Languages✔ Fast Evolution

!

P a t t e r n sP a t t e r n s✔ Plain old C# Objects✔ Bounded Roles✔ Shared Identifiers✔ CQS & Idempotence✔ Observable Entities✔ SOLID Principles✔ Linq Repositories✔ Single Mutable State

Shared modeling grammar

Born from experience✔ work together

they help each other

✔ reliablemost valuable asset here

✔ complete the blue booklower the learning curvestandardize modelers' skills

http://epic.tesio.it/doc/manual.html

●P l a i n o l d P l a i n o l d CC ## O b j e c t s O b j e c t sAim for

✔ Nothing but business

Keep it simpleConsistent for Experts

✔ Typed explicitness

Declarative: bits are cheaper than bugs!

✔ Stable contracts

Interfaces, Identifiers,EventArgs, Exceptions

Avoid✔ Framework-like naming

conventions✔ Your own abstractions✔ Technological

dependencies

Explicit: dll referenceImplicit: virtual members

✔ To worry about db

B o u n d e d R o l e sB o u n d e d R o l e s✔ Points of view

Partition complexityKeep the language consistent and simpleRequire translations

✔ Often present in U.L.✔ Explicit access rules✔ Are junction points

Belong to ModelBelong to Infrastructure

S h a r e d I d e n t i f i e r sS h a r e d I d e n t i f i e r s✔ Concrete Contracts

ImmutableStrongly typed!(string || long)Validate in constructorKey in Identity Maps

✔ Decouple entities ✔ Decouple contexts✔ Avoid naming

conventions

SHARED ! ! !✔ Between players✔ Between layers✔ Between contexts (often)

C . Q . S . & I d e m p o t e n c eC . Q . S . & I d e m p o t e n c eCommands

✔ Void Imperative(out params, if needed)

✔ Have side-effects✔ Throw Typed Exceptions✔ Fire Events (properly)

(Entities' Factories here!)

Queries✔ Return value✔ Free from side-effect✔ Failures are bugs!✔ Thread safe (easily?)

(V.O.'s Factories here!)

Neither should change the arguments!

Both should be IDEMPOTENT (this = 1st operand)

O b s e r v a b l e E n t i t i e sO b s e r v a b l e E n t i t i e sIdentity Evolution

C# as reporter✔ Who? The Sender!✔ What? Event Name

most of times, contains a verb in past tense

✔ Where? EventArgs!✔ When? On callback!✔ Why? Decoupling.

No Domain Events?✔ Implicit

need to read the code

✔ A bit Java oriented✔ Wait, we have them!

You just need an observer inside repository or Epic.Server

What's about Earthquakes?

S i n g l e R e s p o n s i b i l i t yS i n g l e R e s p o n s i b i l i t y The One Reason

✔ Business evolutionBusiness evolution✔ deeper insights✔ bug fixes

Split contexts properly

Forget # of methods

No “helper” overloads!

O p e n - C l o s e dO p e n - C l o s e d✔ Well bounded contexts✔ Small design decisions

Template methods (!)SerializableAttribute

Single Mutable State

Allow Binary Reuse

Break (with Branch)

on Deeper Insight

L i s k o v S u b s t i t u t i o nL i s k o v S u b s t i t u t i o n✔ Always forgot✔ Concerns abstractions✔ Easy... if you don't

abstract on your own

small inheritance depth(most of times...)

✔ Developers hate it(until debug)

What's about events?And exceptions?

I n t e r f a c e S e g r e g a t i o nI n t e r f a c e S e g r e g a t i o n✔ Clear Contexts == Small Classes

✔ Anti-corruption layers (domain services)✔ Shared kernels

contain contracts only with or without a roleshould emerge from existing codeshould be carefully analized (no “coding convention”)

✔ Avoid multiple inheritance

different interfaces == divergent evolutions

D e p e n d e n c y I n v e r s i o nD e p e n d e n c y I n v e r s i o na)High-level modules

should not depend on low-level modules. Both should depend on abstractions.

b)Abstractions should not depend on details. Details should depend on abstractions.

– Robert Martin (2002)

Domain ModelsContracts Code

(highest levels)

Any thing else✔ Persistence✔ User Interfaces✔ Infrastructure

Epic itself is replaceable(lower levels)

L i n q R e p o s i t o r i e sL i n q R e p o s i t o r i e s✔ Generic Repositories

Consistent API – Select<T>(QueryObj)– Save<T>(T) (?!)– Delete<T>(T) (?!)

Easy with O/RMIMPLICIT! ! !

✔ Custom repositories

explicit interfaces (pro)harder to maitain (cons)

IQueryable<TEntity>✔ Explicit (and complete)

stable and consistentneeds declarative types

✔ Decouple

clients ignore executorscan inject infrastructure

✔ Derive IRepository<T>

ease versioningcan blend to custom rep

S i n g l e M u t a b l e S t a t eS i n g l e M u t a b l e S t a t e✔ Optional design pattern for entities

preserves the model expressivityallows concurrent access to entities

✔ Fine grained locks

a single field contain the statethe state – is immutable– replicate entity's api but instead of void returns next state

on command: execute, compare & swap✔ Designed for Epic.Server

a “transparent” CQRS grid, at need

A r c h i t e c t u r e sA r c h i t e c t u r e sTechnological req.

✔ Modularization

binary reuse (up to views)

decoupled cooperation✔ High scalability✔ Easy integration

● SOA is not enough!

Business req.✔ MiFID (2004, 2006... 2011?)

complex financial ruleson human processes“implemented” by banks“strict” compliance

✔ Dispatch orders!

Sync with trading online

No Ring to rule them all!

C h o o s i n g t h e B u s i n e s sC h o o s i n g t h e B u s i n e s s✔ We decided to protect the Domain Knowledge

customers find techicalities weirdcustomers love who talk their language

✔ Looking for perceptible excellence

we want to compete on value instead of pricewe want to build custom applications – rapidly adapted to the customers' environments and needs– on top of stable products (and assemblies)

We built a set of brand-new tools!

I n n o v a t i o n & R i s kI n n o v a t i o n & R i s kFrameworks are Risky Investments!

✔ P = f(D) + f(A)P = productivity gainf = architects' skills

● technical, social, economicD = investment in design & development (doc & edu included)A = alternatives' evaluation

Found no alternatives?

Build next Secret Weapon!

3 - t i e r s3 - t i e r s1 )1 )

M i c r o s o f t D D D N - L a y e rM i c r o s o f t D D D N - L a y e r2 )2 )

M i c r o s o f t D D D N - L a y e rM i c r o s o f t D D D N - L a y e r2 )2 )

Onion ArchitectureOnion Architecture3 )3 )

T h e D a i s y A r c h i t e c t u r eT h e D a i s y A r c h i t e c t u r e

T h e D a i s y A r c h i t e c t u r eT h e D a i s y A r c h i t e c t u r e

T h e D a i s y A r c h i t e c t u r eT h e D a i s y A r c h i t e c t u r e

D r e s s t h e M o d e lD r e s s t h e M o d e l...with Epic's petals!

✔ Epic.Linq

Composable Query Provider✔ Epic.Proxy

More than AOP✔ Epic.Poem

Asp.NET, WPF, MonoTouch✔ Epic.Security✔ Epic.Server

Transparent CQRS/ES

A n E p i c I n v e s t m e n tA n E p i c I n v e s t m e n t✔ Technically challenging✔ Estimated ~ 400.000 €

dual-licensing model✔ Still Work in Progress

15% done in one yearLooking for developers

✔ Target niche markets

DDD applications onlyFor skilled OOP devsWorld wide

Thanks!

http://epic.tesio.it/giacomo@tesio.it