• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Epic.NET: Processes, patterns and architectures
 

Epic.NET: Processes, patterns and architectures

on

  • 1,493 views

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.

Statistics

Views

Total Views
1,493
Views on SlideShare
1,352
Embed Views
141

Actions

Likes
1
Downloads
12
Comments
0

5 Embeds 141

http://epic.tesio.it 132
http://lanyrd.com 4
http://www.linkedin.com 2
http://www.feedspot.com 2
http://feeds.feedburner.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Epic.NET: Processes, patterns and architectures Epic.NET: Processes, patterns and architectures Presentation Transcript

    • Processes, patterns and architectures http://epic.tesio.it/ giacomo@tesio.it
    • Pro cess✔ Choose DDD✔ Find Domain Experts✔ Choose Modelers✔ Discover Contexts✔ Distill Languages✔ DevPool.Start(...)✔ Measure
    • 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
    • Wh o needs an Expert?
    • 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)
    • 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
    • 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)
    • 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.
    • 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
    • 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
    • ● 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
    • 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
    • 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)
    • 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)
    • 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.
    • Single Resp onsibility The One Reason ✔ Business evolution ✔ deeper insights ✔ bug fixes Split contexts properly Forget # of methods No “helper” overloads!
    • Open - Closed✔ Well bounded contexts✔ Small design decisions Template methods (!) SerializableAttribute Single Mutable State Allow Binary Reuse Break (with Branch) on Deeper Insight
    • 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?
    • 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
    • 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)
    • 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
    • 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
    • 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!
    • 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!
    • 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!
    • 1) 3-tiers
    • 2 ) M i c r o s o ft D D D N - L a y e r
    • 2 ) M i c r o s o ft D D D N - L a y e r
    • 3) Onion Architecture
    • Th e Dai s y Ar chit e c t ure
    • Th e Dai s y Ar chit e c t ure
    • Th e Dai s y Ar chit e c t ure
    • 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
    • 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
    • Thanks!http://epic.tesio.it/ giacomo@tesio.it