Epic.NET: Processes, patterns and architectures
- 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