Publicité

Brownfield Domain Driven Design

Director of Engineering @ Rocket Labs GmbH à Rocket Labs GmbH & Co.KG
17 May 2015
Publicité

Contenu connexe

Publicité

Brownfield Domain Driven Design

  1. Brownfield Domain Driven Design Bring your project to the next level without breaking things (nor people)
  2. About me @nicolopigna - PHP developer - Team leader / Software engineer at Rocket Labs, Berlin We proudly run Seller Center, the largest Rocket Internet Marketplace solution. Popular clients: Zalando (Europe), Lazada (south Asia), Linio (south America), Global Fashion Group
  3. Why “Brownfield”? More challenging and fun than greenfield! Majority of cases. Open knowledge harder to find. Examples start from the assumption of a greenfield. “Greenfield is exciting at first, but taking a brownfield project and giving it new life, well, is just priceless!” Me on Twitter
  4. Why Domain Driven Design? ● Non-trivial domain model ● Linguistic boundaries applied to the code ● Design and code reflect the same concepts 1:1 ● Iterative knowledge distillation ● Both tactical and strategic tools
  5. No, let’s not CRUDish applications Generic subdomains Yes, we can ● In your core domain ● In heavy business-logic parts of your application ● In strategic supporting domains Where should I apply it? i.e. where you make most of your money. Can we outsource or buy it? Then it’s one of those.
  6. Is it difficult? How do we change? Team ● learn new concepts ● mindshift is not immediate ● eradicate CRUD design ● design business first, then data structures Management ● handle the change ● manage adaptation time ● active part of design process Organisation ● involve business experts ● face potential change ● introspect processes
  7. Your brownfield Monolithic High-coupling Single-data-store We-tried-to-build-some-unit-tests-but-it’s-impossible-to-mock- everything-or-refactor-let’s-use-integration-tests-instead. *all the bad things in this slide are written with Comic Sans and poor contrast on purpose. Huge Change-here-break-there
  8. BIG BALL OF “MUD”
  9. BIG BALL OF “MUD” Hey, at least it works... Don’t know exactly how, but it does!
  10. Where to start from? Ok, we need some Repositores, then a Domain/Model directory which will contain AggregateRoots, Entity, ValueObjects, etc. Yes! Oh, don’t forget about Domain Services, the Application layer and a new event system which we’ll definitely need. What about a new structure for controllers and UI? They’re definitely part of our Bounded Context! Let’s reuse our DB connection class, so we also need a Shared Kernel.
  11. Instead...
  12. Context mapping ● Define your core domain, supporting and generic subdomains ● Define the relations between them and with other external systems ● Define behavior at boundaries and grey areas
  13. Event storming ➔ Describe your business through events, what/who caused them, what is the “subject” of your events. ➔ Invite the “right people”, brainstorm, discuss, reach a first representation of your business model. Just let it happen.
  14. DON’T JUST SKIP IT! Ubiquitous Language The UL is what takes all things (and people) together. - It dramatically lowers communication and cognitive load, providing a common ground, understandable by anyone. - It defines and explains what domain objects are, how they behave and the relations between them. How can you even start coding something that you haven’t defined in terms of concept and behavior!?
  15. Ok. Finally...
  16. Yeah! We’re finally writing some code now! Markers and sticky notes were making me feel so uncomfortable... The evil facilitator shouted at me when I said “cronjob” :’( We were always talking about “Product”, but I think I will call this class “Article”. Buhahaha! product.name is varchar(50) or varchar(255)?
  17. Where should we start applying DDD from? Are we confident with DDD, SOLID and refactoring strategies? Let’s start with our Core Domain yes Did someone at least read the Blue and Red books? no yes no Let’s start with a Supporting Subdomain Read them...
  18. Keep your UI away CONTROLLERS FORMS TEMPLATES YOUR FAVORITE MVC FRAMEWORK Services (Endpoint / Private) Model Repositorie s Commands Events ✗ ✓
  19. CQRS? Yes, please! Your database Command “Write” Model ● Expresses your business behavior ● Changes the state of the system ● Doesn’t expose internal state Query ● Shapes information based on representation type ● Never changes the state of the system ● Exposes internal state “Read” Model
  20. Haiku of the code duplication CQRS is applied, duplication comes in. Everything is quiet.
  21. Change your state through events DoSomethingCommand Service Unit Of Work load($aggregateRootId) AggregateRoot doSomething() AggregateRootAggregateRoot ● Something Done Repository AggregateRootcommit() flushEvents() Events persist($events) EventBus post($events)
  22. Event sourcing? Read storage? IT’S A TRAP!
  23. Event sourcing? Read storage? 1 - Added architectural complexity Event application Event replaying Snapshots
  24. Event sourcing? Read storage? 1 - Added architectural complexity Event application Event replaying Snapshots 2 - Infrastructure and costs Dedicated data storage (forget MySQL!) Remote communication (via message broker, REST interface, etc.)
  25. Event sourcing? Read storage? 1 - Added architectural complexity Event application Event replaying Snapshots 2 - Infrastructure and costs Dedicated data storage (forget MySQL!) Remote communication (via message broker, REST interface, etc.) 3 - Eventual consistency Think about consequences Implement resilient behavior Advanced UI techniques
  26. Oh! Think twice!
  27. Protect your new code! STRICT RULE: Code from the Big Ball of Mud must not leak into the new BCs nor vice-versa. THEN HOW DO THEY INTERACT? BY MAGIC?
  28. MEET THE ANTI-CORRUPTION LAYER
  29. MEET THE ANTI-CORRUPTION LAYER YOU SHALL NOT PASS!!!
  30. MEET THE ANTI-CORRUPTION LAYER YOU SHALL NOT PASS!!! At least, not before I can convert you to something meaningful for your destination context...
  31. Anti-corruption layer Legacy context Database ACL Adapters Converters Identity Maps Bounded Context
  32. Anti-corruption layer Legacy context Database ACL Adapters Converters Identity Maps I’m here to stay!!! Bounded Context
  33. Anti-corruption layer Legacy context Database ACL Bounded Context Adapters Converters Identity Maps place interfaces here I’m here to stay!!!
  34. Anti-corruption layer Legacy context Database ACL Adapters Converters Identity Maps I can fly away, now! Bounded Context place interfaces here
  35. What happens next? My new shiny BC Our soon-to-be-shrunk BBoM Anti-corruption layer
  36. What happens next? My new shiny BC Our shrinking BBoM Anti-corruption layer My second shiny BC
  37. What happens next? My new shiny BC Our shrinking BBoM Anti-corruption layer My second shiny BC
  38. What happens next? My new shiny BC Our shrinking BBoM Anti-corruption layer My second shiny BC But of course it’s easier now!
  39. From distributed Bounded Contexts to μServices μS = lim Bc(nuc)nuc→ 1
  40. Thank you for listening! Time for muddy questions!

Notes de l'éditeur

  1. ...which means that transitions should never be painful, cause troubles nor resulting in neverending refactoring sessions.
  2. SC bootstrapped in 3 months, features added one after another, thus resulting now in some problems controlling the codebase and solving bugs.
  3. hands up people working on projects younger than 6 months. now older. from the latter, who thinks that their codebase already need some refactoring / has problems.
  4. what is a supporting subdomain. what is a generic subdomain. why not in crudish apps
  5. stress “don’t start designing from data”. stress on “introspect processes” to introduce the next Matrix slide.
  6. ask
  7. Stress on why CQRS is a “natural” good choice. Explain the differences btw simplified and “full” cqrs architecture
Publicité