1.
ABOUT ME
Developer @Adform – www.adform.com
https://lt.linkedin.com/in/raimondastijunaitis

2.
WHAT THIS TALK IS NOT ABOUT
„Best Practices“
Deep dive into DDD, CQRS, Event Sourcing
Refactoring

3.
WHAT IT IS ABOUT
Common (for some of us) software complexity
issues
Techniques that might help and were tried in
production
Continuous/Iterative decoupling

4.
THE DUNGEON

5.
ISSUES
Platform coupling
Model ambiguity
Growing learning curve

6.
SCREW MUSHROOMS, GIVE ME GUNS

7.
LEVEL 1 – DE-NORMALIZED MODELS
Specifically designed for quering
Built asynchronously
Messages dispatched from legacy code

8.
SALVATION WITH EVENTS
Send Message

9.
DE-NORMALIZED MODEL
Project
Ad
Deactivated
Ad
Updated
Ad
Created

10.
OTHER POSSIBLE WAYS
SQL Server replications
Depends on consumer count and your system load
Replicates the same relational structure
SQL Server Message Broker
Queue based message publishing
Custom data messages
Re-use write-model + caching
Be careful with excessive indexing – this might harm your
writes
Cache rebuild and invalidation issues

11.
READ MODELS
NEW WEAPON UNLOCKED

12.
MEET NEW ENEMIES (FRIENDS?)
Eventual consistency
Consistency is a myth
Talk with your business people
Tradeoffs
Idempotency and ordering
Event versions
Read-model versions
What about 1 thread?
Desynchronization
Create sync tools

13.
LEVEL 2 – SYNERGY BETWEEN SYSTEMS
Avoid adding new features into monolith
Avoid big-bang reworks
Use strategic design to handle complexity

14.
REWORK != REFACTORING
Two systems side-by-
side works together
Iterative functionality
migration
In-syncOld
System
New
System
Sync

15.
TIP: Sometimes it is
better to start over
TIP: Having backup
strategy keeps your
blood pressure low
TIP: Go live ASAP

16.
SEPARATE INFRASTRUCTURE FROM
BUSINESS LOGIC

17.
TIP: Identify
infrastructure code
and separate it
TIP: Use different
models for different
tasks

18.
STRATEGIC DESIGN
NEW WEAPON UNLOCKED

19.
LEVEL 3: WRITE MODEL DESIGN
Accepts commands
only
Does not provide
reading operations
Commands results into
sequence of events
Events are immutable
and persisted into
EventStore
Commands RabbitMQ
Banner
Management
Service
Event Store
Events

20.
OR ANY OTHER ORM FRAMEWORK
Aggregates emit events
Aggregates are de-hydrated by replaying historical
events
No setters/getters
Respect encapsulation
NO HIBERNATE

21.
TIP: Events and
commands can be very
natural constructs
TIP: Excluding query
operations can
simplify code a lot

22.
COMMANDS AND EVENTS
NEW WEAPON UNLOCKED

23.
LEVEL 4: EVENT STORE
Stores series of immutable events
There is no delete
Acts as “Event Log”
Has built in projection engine
Is not designed for querying
BannerCreated BannerClickUrlsAdded BannerRenamed BannerRenamed

24.
EVENT SOURCING
NEW WEAPON UNLOCKED

25.
Performs left-folding of
historical events
Produces
projections/views into
streams
Event selection
LEVEL 5: PROJECTIONS
Banner Projection
Click Urls
changed
Image
Renamed
Image
Created
Publishing UI Tags

26.
PROJECTIONS
NEW WEAPON UNLOCKED

27.
Two way synchronization
Anti-corruption layer patters
LEVEL 6: STAYING IN SYNC

28.
SYNC: NEW TO OLD
Banner
Event
Event Store
Dispatcher
ACL Service
RabbitMQ
AdministrationDB
Reacts to domain
events
Makes changes into
AdsministrationDB
within small
transactions
Uses Dapper to
simplify persistence

29.
SYNC: OLD TO NEW
Legacy event
ACL Service
RabbitMQ
Reacts to legacy
events
(AdCreated/AdUpd
ated)
ACL transforms
events into
commands
Aggregates are
updated
Banner
Management
Service
Commands From old
system
Events

30.
TIP: Make legacy
integration
interactions explicit

31.
ANTI-CORRUPTION LAYERS
NEW WEAPON UNLOCKED

32.
LEVEL 7: API
This is the only way to interact with your system
Build UI on top of the API
Versioning is difficult – think if you really need it

33.
EXPOSE COMMANDS AS RESOURCES
PUT: http://.../ImageBaner/{uuid}/Name
Command: RenameBanner
PUT: http://.../ImageBaner/{uuid}/File
Command: ReuploadFile

34.
HYPERMEDIA – HELP YOUR CLIENT
GET: http://.../ImageBanner/{uuid}

35.
HTTP API
NEW WEAPON UNLOCKED

36.
LEVEL 8: UI & UX
Excel is already invented, it’s pretty damn good
UI must be built on top of your API
Guide user through business process

37.
BEFORE

38.
AFTER

39.
TIP: Build UI to solve
business cases but
not to edit data
TIP: Exposing tasks
can reduce overhead
for users and for
developers
TIP: Build UI on top
of the API

40.
TASK BASED UI
NEW WEAPON UNLOCKED

41.
LEVEL 9: TROUBLESHOOTING AND
DEBUGGING
There is no F5 in distributed systems
Correlate all your requests and messages
Use centralized logging services

42.
INSIDE THE RABBIT HOLE
REST
API
Domain
Service
ACL
Service
ES
Dispatcher
Service
Creative
Upload
API
Creative
Upload
Service
Ad
Analyzer
Service
File
Checker
Service
File
Generation
Service
Publishing
Service
Preview
Service

43.
TRACK OPERATIONS

44.
TIP: Track every
operation performance –
this helps to identify
bottlenecks
TIP: Automate load tests
and run them often.

45.
CORRELATION IDS
NEW ITEM UNLOCKED: NIGHT VISION

46.
YOU DON’T NEED THEM ALL - CHOOSE WISELY
De-normalized read models
Strategic design
CQRS
Event sourcing
Projections
ACLs
REST API
Task based UI
Centralized logs
LOTS OF GUNS

47.
BUT WHAT IF…
No guns for
You!!!

48.
ADAPT TO BUSINESS THINKING
Avoid – technical arguments
Code quality is poor
We need to refactor
Technology is old
Everyone is using Angular
now…
Missing “best practices”
We want to try NoSQL…
Prefer – economical arguments
Releases every day
Faster feature development
New products
Involve more developers
MS licenses are expensive…

49.
DON’T GET LOST IN A DUNGEON
Have a VISION
COMMIT
Define Your STRATEGY
Create TACTICS
FIGHT
ADOPT new tactics
Fight HARDER
WIN