Agility is the ability of an organisation to respond to evolving business landscape thus avoiding disruption. A technology enabled business may not achieve this responsiveness if business concepts do not align with representations in technology implementation. Domain Driven Design (DDD) achieves a closer alignment between business concepts and technology implementation, independence between domain model and infrastructure and independence between teams working on different subsystems. Functional software built using DDD is mapped to an architecture that supports NFRs (Non-Functional Requirements) of the system. System NFRs also evolve with the passage of time requiring architectural changes to achieve emerging qualities. A functional design that is loosely coupled with the underlying architecture will significantly reduce the refactoring effort associated with the architectural changes. This talk discusses how DDD localises impact of changes thus enhancing organisational agility in disruptive environments.

1. Technological Agility
https://enterprisersproject.com/article/2018/2/anthem-cio-how-agile-helped-us-drive-value

2. Omar Bashir
Associate Director
https://www.linkedin.com/in/obprofile/
@OmarBashir_40

4. Traditional Agile Transformation
Organisation
Talent
Process
Culture
Process

5. In fact, in an agile project, technical excellence is
measured by both capacity to deliver customer
value today and create an adaptable product
for tomorrow.
Jim Highsmith

6. Agile Transformation for Disruption
Organisation
Talent
Process
Culture
Process
Engineering

7. Technology and Business Change
● Technology optimises business processes.
● Business change necessitates technology
change.
● Not all technology facilitates business change.
– Shorter the time to realise a business opportunity
more challenging is the corresponding technical
change.

8. Inflexible Technology
● Each change adds complexity.
● Complexity leads to brittleness.
● Brittleness leads to further inflexibility.

9. I very frequently get the question: ‘What’s going
to change in the next 10 years?’ And that is a
very interesting question; it’s a very common
one. I almost never get the question: ‘What’s
not going to change in the next 10 years?’
And I submit to you that that second question is
actually the more important of the two—because
you can build a business strategy around the
things that are stable in time…
Jeff Bezos

10. Disruption 101
● Fundamental needs don’t change.
● How these needs are delivered is the
differentiator.
● Leading and managing disruption,
– A strategic focus on the domain.
– Decoupling the domain from delivery mechanisms.
– Enabling extensibility in the domain and flexibility in
delivery.

11. Strategic Focus on Domain
● Domain Driven Design (DDD),
– Focuses on core domain,
– Explores models for creative collaboration between
domain practitioners and software developers.
– Encourages separation of concerns.
● Facilitates,
– Strategic definition of sub-domains and interactions
between them.
– Definition of the domain information models.

13. Domain Model
● Foundation for defining the strategic
representation and deriving infrastructure data
models.
● Consists of
– Entities,
– Value objects
– Events
– Aggregates
– Abstractions
● Factories
● Repositories
● Services

14. Bounded Contexts
● Incremental construction of the domain by domain
decomposition.
– Helps identify generic sub-domains with commoditised
implementations.
– Sub-domains logically separated by bounded contexts.

15. Event Storming
● Rapid, lightweight group modeling technique.
– Capturing domain events without implementation
specifics.
● Using the Ubiquitous Language,
– Capture domain events on a timeline.
– Add triggers,
● Commands causing the events.
– Identify sources of triggers.
– Describe data for every command event pair.
– Identify policies, reactive logic after an event that
triggers other events.

16. Software development is a learning process; working code is a side effect. Alberto Brandolini

17. Bounded Contexts From Event Model
● Pivotal Events
– Indicate major changes in the domain.
– Often form boundaries between sub-domains.
● Swim Lanes
– Event series in overlapped timelines.
● Aggregates
– Logically related entities and value objects.
● E.g., orders and order lines.
– Emerge from grouping of events and commands.

18. Message
Received
Message
Xformed
Message
Validated
Message
Enriched
New Trade
Booked
Trade
Amended
Trade
Cancelled
Trader
Notified
Xform
Failed
Validation
Failed
Enrichment
Failed
Failure
Notified
Trade Moved
To Book
Risk & P&L
Calculated
Pivotal Events
SwimLanes

19. Impact of NFRs
● NFRs (Non-functional Requirements) define
architectural styles on which the functional
design is implemented.
● NFRs also steer infrastructure choices.
● NFRs vary over the life of an application.
– May necessitate adopting different architectural styles
or technologies.
● Tight coupling between functional code and
infrastructure leads to inflexible technology.
● Relegating NFRs in a development cycle leads to
inefficient systems.

20. Reducing Coupling and Leakage
Account
Management
Credentials
Management
LDAP
Access
Management
Database
API

21. Reducing Coupling and Leakage
Account
Management
Credentials
Management
LDAP
Access
Management
Database
API
Generic Sub-domains
Core Domain
Infrastructure

22. Independence
● Reducing dependencies to the minimum.
– Lower app binary footprint.
– Reduce risks.
– Simplify testing.
● Isolating dependencies from functional logic.
– Functional logic need not change when replacing
dependencies.
– Hexagonal architecture

23. Hexagonal Architecture

24. Agility vs Over Engineering
● Over engineered applications
– Cater for all possible eventualities.
– Are prematurely and speculatively optimised.
– Inflexible due to increased complexity.
● Agile applications are
– Flexible and extensible.
– Scalable to increase performance on demand.

25. DIPSy
A Framework for Technological Agility

26. Domain Focus
Independence
Patternise Pragmatically
Simplify Aggressively