Your SlideShare is downloading. ×
Epic.NET: Processes, patterns and architectures
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Epic.NET: Processes, patterns and architectures


Published on

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.

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.

Published in: Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Processes, patterns and architectures
  • 2. Pro cess✔ Choose DDD✔ Find Domain Experts✔ Choose Modelers✔ Discover Contexts✔ Distill Languages✔ DevPool.Start(...)✔ Measure
  • 3. 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
  • 4. Wh o needs an Expert?
  • 5. 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)
  • 6. D i s c ov e r th e Cont ex t s Creative ✔ Identify the CoreCollaboration ✔ 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 dependenciesTrack Decisions! ✔ Schedule works
  • 7. 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)
  • 8. D e v Po o l . S t a r t ( . . . )Once a Context is ready and known to the team, therelated 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.
  • 9. 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
  • 10. 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
  • 11. ● 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
  • 12. 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
  • 13. 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)
  • 14. 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)
  • 15. Observable Entities Identity Evolution No Domain Events? ✔ ImplicitC# 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! Whats about Earthquakes?✔ Why? Decoupling.
  • 16. Single Resp onsibility The One Reason ✔ Business evolution ✔ deeper insights ✔ bug fixes Split contexts properly Forget # of methods No “helper” overloads!
  • 17. Open - Closed✔ Well bounded contexts✔ Small design decisions Template methods (!) SerializableAttribute Single Mutable State Allow Binary Reuse Break (with Branch) on Deeper Insight
  • 18. Li s kov S u b st it ut io n ✔ Always forgot ✔ Concerns abstractions ✔ Easy... if you dont abstract on your own small inheritance depth (most of times...) ✔ Developers hate it (until debug) Whats about events? And exceptions?
  • 19. 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
  • 20. D e p e nde nc y Inv e rs iona)High-level modules Domain Models should not depend on Contracts Code low-level modules. (highest levels) Both should depend on abstractions. Any thing elseb)Abstractions should not ✔ Persistence depend on details. ✔ User Interfaces Details should depend on abstractions. ✔ Infrastructure – Robert Martin (2002) Epic itself is replaceable (lower levels)
  • 21. 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
  • 22. 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 entitys api but instead of void returns next state on command: execute, compare & swap✔ Designed for Epic.Server a “transparent” CQRS grid, at need
  • 23. 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!
  • 24. 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!
  • 25. 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 evaluationFound no alternatives?Build next Secret Weapon!
  • 26. 1) 3-tiers
  • 27. 2 ) M i c r o s o ft D D D N - L a y e r
  • 28. 2 ) M i c r o s o ft D D D N - L a y e r
  • 29. 3) Onion Architecture
  • 30. Th e Dai s y Ar chit e c t ure
  • 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. Dress the Model ...with Epics petals!✔ Epic.Linq Composable Query Provider✔ Epic.Proxy More than AOP✔ Epic.Poem Asp.NET, WPF, MonoTouch✔ Epic.Security✔ Epic.Server Transparent CQRS/ES
  • 34. 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
  • 35. Thanks!