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.

1. Continuous Platformization
JSChannel BLR 2014
Amod Malviya

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. Systems

4. System Elements
Infra
Stories
Domain Semantics
Entities

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. 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. 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. Misconceptions
• Middleware == Domain Semantics
• Abstraction == Domain Semantics
• Externalizing control == Domain Semantics

9. System Elements
Infra
Stories
Domain Semantics
Entities
Solution

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. 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. 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. System Elements
Infra
Stories
Domain Semantics
Entities

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. “Continuous” - For legacy systems
• Two options:
– Seaming
– Alternatively (not recommended):
• Build platform in parallel to existing system

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. Questions?
@amodm
amod@flipkart.com