Epic.NET is a framework composed of a process, a set of patterns and a set of architectural constraints for applications that need to follow the Domain Driven Design principles.
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
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!
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
