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

1,536
views

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,536
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Processes, patterns and architectures http://epic.tesio.it/ giacomo@tesio.it
  • 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 http://epic.tesio.it/doc/manual.html
  • 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!http://epic.tesio.it/ giacomo@tesio.it

×