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!
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