The document outlines a framework for software development, emphasizing Domain-Driven Design (DDD) and various architectural patterns. It discusses the importance of collaboration, context discovery, and shared languages in development, alongside best practices for managing dependencies and ensuring code quality. Additionally, it highlights the need for skilled developers and structured approaches to improve productivity and meet business requirements.

2. Processes, patterns and architectures
http://epic.tesio.it/
giacomo@tesio.it

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

4. Ch oose D.D.D.
✔ Cool? Just expensive!
✔ Requires experience
✔ For applications
business critical
operative
complex beyond tech
✔ Not for
data driven apps
vendor-driven teams

5. Wh o needs an Expert?

6. Ch oose a Modeler
✔ Humble ✔ Out of touch devs
✔ Motivated ✔ Inexperienced devs
✔ Smart ✔ Technologists
✔ Fearless ✔ Hackers
✔ Really skilled in OOP ✔ Unmotivated people
✔ Diligent ✔ Sociopathics
✔ Comunicative ✔ Leaving company
✔ Responsible ✔ Yielding people
(responsum abilem)

7. D i s c ov e r th e Cont ex t s
Creative ✔ Identify the Core
Collaboration ✔ Identify supporting
contexts
Domain Expert
(Business Experience) ✔ Name each context
vs think to namespaces
Modeler ✔ git add VISION.txt
(Development Needs)
(vision statement)
✔ Look for dependencies
Track Decisions!
✔ Schedule works

8. Distill Languages
✔ Bounded Context → Point of View / Language
✔ Context Name → Namespace (Project?)
✔ Distill Language → Write Contracts (POCO)
ITERATE ! ! !
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)

9. 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.

10. Measure (to estimate)
✔ Customer feedbacks Look For
✔ # / € of Bugs
✔ Global Optimum
✔ Modeling Effort
✔ Explicitness/Precision
✔ Development Effort
✔ Shared Languages
✔ Breakthroughs
✔ Fast Evolution
!
✔ Refactorings
Analyze Failures
✔ Parallelization issues
to
✔ Reuse opportunities
Reduce Risks

11. Pa t t e r n s
✔ Plain old C# Objects Shared
✔ Bounded Roles modeling grammar
✔ Shared Identifiers Born from experience
✔ CQS & Idempotence ✔ work together
they help each other
✔ Observable Entities
✔ reliable
✔ SOLID Principles most valuable asset here
✔ Linq Repositories ✔ complete the blue book
✔ Single Mutable State lower the learning curve
standardize modelers' skills
http://epic.tesio.it/doc/manual.html

12. ●
Plain old C# Objects
Aim for Avoid
✔ Nothing but business ✔ Framework-like naming
Keep it simple conventions
Consistent for Experts ✔ Your own abstractions
✔ Typed explicitness ✔ Technological
Declarative: bits are dependencies
cheaper than bugs!
Explicit: dll reference
✔ Stable contracts Implicit: virtual members
Interfaces, Identifiers, ✔ To worry about db
EventArgs, Exceptions

13. Bounded Roles
✔ Points of view
Partition complexity
Keep the language
consistent and simple
Require translations
✔ Often present in U.L.
✔ Explicit access rules
✔ Are junction points
Belong to Model
Belong to Infrastructure

14. S h a r e d I d e n t i fi e r s
✔ Concrete Contracts
Immutable
Strongly typed
!(string || long)
Validate in constructor
Key in Identity Maps
✔ Decouple entities SHARED ! ! !
✔ Decouple contexts ✔ Between players
✔ Avoid naming ✔ Between layers
conventions ✔ Between contexts (often)

15. C.Q.S. & Idemp otence
Commands Queries
✔ Void Imperative ✔ Return value
(out params, if needed) ✔ Free from side-effect
✔ Have side-effects ✔ Failures are bugs!
✔ Throw Typed Exceptions ✔ Thread safe (easily?)
✔ Fire Events (properly) (V.O.'s Factories here!)
(Entities' Factories here!)
Neither should change the arguments!
Both should be IDEMPOTENT (this = 1st operand)

16. Observable Entities
Identity Evolution No Domain Events?
✔ Implicit
C# as reporter need to read the code
✔ A bit Java oriented
✔ Who? The Sender!
✔ Wait, we have them!
✔ What? Event Name
You just need an observer
most of times, contains inside repository or
a verb in past tense Epic.Server
✔ Where? EventArgs!
✔ When? On callback! What's about
Earthquakes?
✔ Why? Decoupling.

17. Single Resp onsibility
The One Reason
✔ Business evolution
✔ deeper insights
✔ bug fixes
Split contexts properly
Forget # of methods
No “helper” overloads!

18. Open - Closed
✔ Well bounded contexts
✔ Small design decisions
Template methods (!)
SerializableAttribute
Single Mutable State
Allow Binary Reuse
Break (with Branch)
on Deeper Insight

19. Li s kov S u b st it ut io 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?

20. I n t e r fa c e S e g r e g at i o n
✔ Clear Contexts == Small Classes
✔ Anti-corruption layers (domain services)
✔ Shared kernels
contain contracts only
with or without a role
should emerge from existing code
should be carefully analized (no “coding convention”)
✔ Avoid multiple inheritance
different interfaces == divergent evolutions

21. D e p e nde nc y Inv e rs ion
a)High-level modules Domain Models
should not depend on Contracts Code
low-level modules. (highest levels)
Both should depend on
abstractions. Any thing else
b)Abstractions should not ✔ Persistence
depend on details. ✔ User Interfaces
Details should depend
on abstractions. ✔ Infrastructure
– Robert Martin (2002) Epic itself is replaceable
(lower levels)

22. Lin q Re p os ito r ie s
✔ Generic Repositories IQueryable<TEntity>
Consistent API ✔ Explicit (and complete)
– Select<T>(QueryObj)
stable and consistent
– Save<T>(T) (?!)
needs declarative types
– Delete<T>(T) (?!)
Easy with O/RM
✔ Decouple
IMPLICIT! ! ! clients ignore executors
✔ Custom repositories can inject infrastructure
explicit interfaces (pro)
✔ Derive IRepository<T>
harder to maitain (cons) ease versioning
can blend to custom rep

23. Single Mutable State
✔ Optional design pattern for entities
preserves the model expressivity
allows concurrent access to entities
✔ Fine grained locks
a single field contain the state
the 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

24. A r chit e c t ure s
Technological req. Business req.
✔ Modularization ✔ MiFID (2004, 2006... 2011?)
binary reuse (up to views) complex financial rules
decoupled cooperation on human processes
✔ High scalability “implemented” by banks
“strict” compliance
✔ Easy integration ✔ Dispatch orders!
● SOA is not enough!
Sync with trading online
No Ring to rule them all!

25. Ch oosing th e Business
✔ We decided to protect the Domain Knowledge
customers find techicalities weird
customers love who talk their language
✔ Looking for perceptible excellence
we want to compete on value instead of price
we 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!

26. Innovation & Risk
Frameworks are Risky Investments!
✔ P = f(D) + f(A)
P = productivity gain
f = architects' skills
● technical, social, economic
D = investment in design & development (doc & edu included)
A = alternatives' evaluation
Found no alternatives?
Build next Secret Weapon!

27. 1) 3-tiers

28. 2 ) M i c r o s o ft D D D N - L a y e r

29. 2 ) M i c r o s o ft D D D N - L a y e r

30. 3) Onion Architecture

31. Th e Dai s y Ar chit e c t ure

32. Th e Dai s y Ar chit e c t ure

33. Th e Dai s y Ar chit e c t ure

34. Dress the Model
...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

35. An Epic Investment
✔ Technically challenging
✔ Estimated ~ 400.000 €
dual-licensing model
✔ Still Work in Progress
15% done in one year
Looking for developers
✔ Target niche markets
DDD applications only
For skilled OOP devs
World wide

36. Thanks!
http://epic.tesio.it/
giacomo@tesio.it