Continuous Platformization
JSChannel BLR 2014
Amod Malviya
CP
• Is not about JS techniques
• Is about design & engineering patterns
– Surprisingly less talked about
– Most common re...
Systems
System Elements
Infra
Stories
Domain Semantics
Entities
Entities
• The “nouns” of your systems
• Have an “identity” and a “lifecycle”
• The code “understands” them
• Little code
...
Stories
• The “use cases”
• The “workflows” that your users go through
• Control paths triggered through biz events
• High...
Domain Semantics
• Capabilities that enable many stories
• Behavior, Policy et al.
• Augmented information about entities
...
Misconceptions
• Middleware == Domain Semantics
• Abstraction == Domain Semantics
• Externalizing control == Domain Semant...
System Elements
Infra
Stories
Domain Semantics
Entities
Solution
Platforms vs Solutions
• Solutions
– Start with stories
– Bypass semantics
– Connect stories directly with entities
– Rigi...
How to build Platforms
• Think a lot about base constructs (entities &
semantics)
• Identify & create semantics to the ext...
A risk…
• Deeper thinking can sometimes lead to
– Slower speed of execution (Bad)
– Complete stall (Worse)
– Over engineer...
System Elements
Infra
Stories
Domain Semantics
Entities
Make it continuous
• Use an iterative model
– Move step by step with sprints
– Every sprint leads to a few steps closer to...
“Continuous” - For legacy systems
• Two options:
– Seaming
– Alternatively (not recommended):
• Build platform in parallel...
Parting Thoughts
• Build Platforms, not Solutions!
• Cautionary Note
– There’s no one framework to rule them all
– More a ...
Questions?
@amodm
amod@flipkart.com
Upcoming SlideShare
Loading in …5
×

Continuous Platformization

801 views
627 views

Published on

Continuous Platformization is a collection of best practices that mixes elements of Domain Driven Design, Agile and Service Oriented Architecture, to help organisations strike effective balance between short term agility and long term sustainability of systems.

Published in: Engineering
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
801
On SlideShare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Thanks for having me over
    Nervous about presenting to smart people - am I doing justice to their time?
    Have not been successful in talking about this in 1 hr in the past
  • Have been characterizing systems for a long time now. This is a presentation of that study
  • Need to understand “systems” before platforms
  • Not an issue in system design – too many frameworks out there to make life easy. OOD is a very well understood domain now (at least entities)
  • Capability: Interview scheduling
    Behaviour/Policy: Don’t overblock
    Augmented: Which companies?
    Externalize control: e.g. pricing systems – for autonomous pricing, my system needs to be able to “learn” pricing intent
  • ACL: Anti Corruption Layer
    Interesting patterns on stories – self mutating stories, stories in database, reflective stories
  • Servificy – this is where the SOA piece comes into picture
  • This is where the agile piece comes into picture
  • Seaming: Michael Feathers
    Parallel platform: will always slip. Higher risk with longer projects, newer requirements
  • - Help make it better: 1) Give me data points about when systems succeed/fail, 2) Participate in the thought process
  • Continuous Platformization

    1. 1. Continuous Platformization JSChannel BLR 2014 Amod Malviya
    2. 2. CP • Is not about JS techniques • Is about design & engineering patterns – Surprisingly less talked about – Most common reason for system failures/rewrites – Particularly important in the age of dynamic languages • Elements of DDD, Agile & SoA • Helps address short term vs long term • WIP – help make it better
    3. 3. Systems
    4. 4. System Elements Infra Stories Domain Semantics Entities
    5. 5. Entities • The “nouns” of your systems • Have an “identity” and a “lifecycle” • The code “understands” them • Little code – But most pervasive across the code • Usually not an issue in system design
    6. 6. Stories • The “use cases” • The “workflows” that your users go through • Control paths triggered through biz events • Highest volume of code • The most frequently changed code
    7. 7. Domain Semantics • Capabilities that enable many stories • Behavior, Policy et al. • Augmented information about entities • Externalize control – Provide a higher abstraction to work with • Retain Semantics
    8. 8. Misconceptions • Middleware == Domain Semantics • Abstraction == Domain Semantics • Externalizing control == Domain Semantics
    9. 9. System Elements Infra Stories Domain Semantics Entities Solution
    10. 10. Platforms vs Solutions • Solutions – Start with stories – Bypass semantics – Connect stories directly with entities – Rigid, difficult to maintain beasts • Platforms – Start with domain constructs – Have guaranteed semantics – More robust (e.g. can have ACLs) – Externalize control – Stories are easier to read – Enable interesting patterns on stories
    11. 11. How to build Platforms • Think a lot about base constructs (entities & semantics) • Identify & create semantics to the extent possible • Servicify the platform – Forces separation of platform & stories – Forces contracts between semantics & stories • Build stories on top of this platform – Instead of building it within the platform
    12. 12. A risk… • Deeper thinking can sometimes lead to – Slower speed of execution (Bad) – Complete stall (Worse) – Over engineering ! (Worst) • Similarity with short term vs long term? – Short term optimizes for time to market – Long term optimizes for maintainability, extensibility & scalability
    13. 13. System Elements Infra Stories Domain Semantics Entities
    14. 14. Make it continuous • Use an iterative model – Move step by step with sprints – Every sprint leads to a few steps closer to ideal • Optimize for contracts – lock those in early! – Changes go through a much more rigorous review • Prioritize for time to delivery – Within the contract, hack away to glory • Cap out the “deep thinking” time penalty: 15% per sprint works for me
    15. 15. “Continuous” - For legacy systems • Two options: – Seaming – Alternatively (not recommended): • Build platform in parallel to existing system
    16. 16. Parting Thoughts • Build Platforms, not Solutions! • Cautionary Note – There’s no one framework to rule them all – More a guiding principle than a bible • CP is an evolving concept – Help make it better • Recommended reads – Eric Evans: Domain Driven Design – Michael Feathers: Working Effectively With Legacy Code
    17. 17. Questions? @amodm amod@flipkart.com

    ×