How to connect product management and software engineering. In order to connect the time old divide between product management/sales with software development, Domain Driven Design contains a series of paradigm changes and techniques to deal with complexity which align the vision of the product and the learning that the development team get from it. Contains code samples in Python to illustrate the concepts. Presented at Python Floripa 2017 meetup.

1. NewStore Inc.
Domain Driven Design!
... or how to connect engineering
and product management.
Bernardo Torres
btorres@newstore.com
http://www.newstore.com/

2. NewStore Inc.
Topics
∖ Tension between Product and Engineering
∖ NewStore’s Journey with DDD
∖ Strategic Patterns of DDD
∖ Forming contexts around subdomains
∖ Event Storming
∖ Tactical Patterns of DDD
∖ NewStore
Agenda
2

3. NewStore Inc.
Tension Between Product and Engineering
Product/Sales wants:
∖ A cool, good looking product
∖ A thousand features
∖ Sales wants fixed dates
∖ Issues: Epics and User Stories
∖ When? Yesterday
3
Engineering needs:
∖ A consistent, understandable,
pluggable architecture
∖ Low tech debt
∖ Issues: Tech Stories and Bugs
∖ When? When it’s ready

4. NewStore Inc.
Proxy between developers and the outside world
∖ Role is based on constant negotiation between engineering and Sales
∖ Replaces the Business Analyst from Waterfall paradigm
○ Focused on features / product (platform) building
Dark Side
∖ Not always Domain Experts
∖ Can fall into pressure from Sales to break Scrum process
∖ Can isolate developers from the real world: lost in translation effect
What to do?
∖ Should be made aware of the role and implications of good/bad architecture
○ Bugs and slow Time To Market
∖ Antipattern: refactoring sprint / bug killing sprint
Product Owner
4

5. NewStore Inc.
Founded by Stephan Schambach, ecommerce pioneer who started
Intershop & Demandware (now Salesforce Commerce Cloud)
∖ Ecommerce as a platform (specifically Mobile Retail)
○ Provides the multi-tenant platform + APIs that plug into your ecommerce workflow
■ Integrates with 3rd party providers (shipment, payment, taxes)
○ From product browsing all the way to delivery (and everything in between)
○ Provides a Retail App that is used by associates
○ Provides a SDK that can be used to build a Consumer App
■ Some companies build “on their own” (adidas)
■ Some companies have it built by NewStore
∖ adidas GLITCH
NewStore - what we do
5

6. NewStore Inc.
Microservices at NewStore
6
Payment
Microservice
Shipment
Microservice
Backend-For-
Frontend
MicroserviceHTTP BFF MS
BFF MS
Rabbit
MQ
Events & RPC
Consumer App
HQ App
HTTP
Retail App
HTTP

7. NewStore Inc.
Main books:
∖ Domain Driven Design - Eric Evans
∖ Implementing Domain Driven Design - Vaughn Vernon
Principles that drive modeling as a iterative learning process
∖ Implementation is an expression of knowledge of the domain
∖ Connecting model and implementation
∖ Ubiquitous Language
∖ Context Mapping
∖ Interaction between Developers and Business Experts
Domain Driven Design
7

8. NewStore Inc.
Books were already known by a fraction
of the team
Reader’s club formed to study it
Always felt that we needed to be more aware of:
∖ Context mapping - interconnection between
teams and contexts
∖ Misalignments between teams/contexts and
their consequences
∖ Make product management aware of
sub-domains/contexts
∖ Finding business experts
NewStore’s Journey with DDD
8

9. NewStore Inc.
Workshop with
Vaughn Vernon
∖ Helped spread the
knowledge around
the teams
∖ Created a bigger
consensus on ideas
which were
perceived by few
NewStore’s Journey with DDD
9

10. NewStore Inc.
∖ Help you make sure you’re using the right models, language and ideas
∖ Best interaction is getting them with you on a whiteboard
∖ Hard to find? Who are they? What do they eat? Where do they live?
∖ Examples
○ Seasoned professionals in the area - experience, but risk of old ideas
○ Integrators - in the front lines of plugging the software with the client’s platform
○ Sales. Yes, Sales. They’re on the trenches and know how clients behave.
○ Support. They know how clients struggle with the product.
○ Interview with client’s employees - video, text, direct.
○ Books
Domain Experts
10

11. NewStore Inc.
∖ Areas of business your
company is into. Can be:
∖ Core: where the
competitive advantage is;
∖ Supporting: a needed
function, but not
strategic;
∖ Generic: no difference
from other systems in the
market.
Domain / Subdomains - Problem Space
11

12. NewStore Inc.
∖ How your company divides to
conquer the business they’re into.
Can be:
∖ Core: main focus of investment;
∖ Supporting: choose between invest
the minimum, hire an outsourcing or
use generic solution;
∖ Generic: able to use generic solution
available in the market.
Antipatterns:
Outsourcing core contexts
Contexts - Solution Space
12

13. NewStore Inc.
∖ Language should be as close to the business as possible
○ Search for the nouns, but also the verbs, the expressions, the models
∖ Divided per context. Example: SalesOrder vs. FulfillmentOrder
∖ Built with Domain Experts: in theory you should be able to show them the code
∖ Code implication:
○ Have business logic separated from infrastructure and presentation layers
Example
Service naming: OrderNotification vs. Email.
Entity naming: Tenant vs. Customer, Consumer vs. Customer.
Antipatterns
∖ Technical / Abstract Language: ProxyAbstractInterfaceAdapter
∖ Naming models after their implementation
Ubiquitous Language
13

14. NewStore Inc.
Teams and contexts should align
∖ Knowledge areas are formed - specialists for each area
∖ Challenges:
○ Reorganizing contexts involves changing people - even hiring when needed
○ Contexts evolve with time - cuts are not static
○ Load of work is very variable between teams
Possible Cuts
∖ By Use Case
∖ Around Features
∖ By Area of Expertise
∖ Chaotic
Antipatterns
∖ Viewing teams as work queues
Context Forming
14

15. NewStore Inc.
Forms contexts around the steps of an order
∖ As an initial cut made a lot of sense
∖ With time (and new features), the loose distribution of areas (e.g. payment, shipment) we
needed tremendous amount of coordination to deliver improvements.
∖ More general architecture around specialized areas was not possible (payment, shipment)
Example
Context Forming - by use case
15
# Buy
Checkout
Tax collector
Sales Order
Payment
Authorization
Shipping Options
# Explore
Product
Catalog
Pricebooks
Import
# Fulfillment
Associate
Shipment
# Routing
Logistics
Stock
# Financials
Reporting
Payment
Capture

16. NewStore Inc.
Let entities emerge naturally from the captured domain
language
∖ Get together with business experts and developers to figure
out the language. Capture (in that order):
○ things that happen in our domain - Events
○ orders that triggers these events - Commands
○ entities that change with these Commands and Events
- Aggregates
○ areas of knowledge that naturally come together and
that naturally are apart - Contexts
∖ Storming: first iterations should avoid discussions
∖ Aligns people on language
Event Storming
16

17. NewStore Inc.
Event Storming - Events
Events
“Consumer Email address updated”
“The payment was rejected for lack of
funds.”
17

18. NewStore Inc.
Event Storming - Commands
Events
“Consumer Email address updated”
“The payment was rejected for lack of
funds.”
18
Commands
“Update Email address”
“Send order confirmation Email”
“Capture Payment”

19. NewStore Inc.
Event Storming - Aggregates
Events
“Consumer Email address updated”
“The payment was rejected for lack of
funds.”
19
Commands
“Update Email address”
“Send order confirmation Email”
“Capture Payment”
Aggregates
”Consumer”
“Inventory Item Availability”

20. NewStore Inc.
Event Storming - Contexts
EventsCommands
Aggregates
EventsCommands
Aggregates
EventsCommands
Aggregates
EventsCommands
Aggregates
Contexts
”Consumer Self Service”
“Consumer Communication”
→ Listen closely to Language
of Domain Experts to identify
Contexts

21. NewStore Inc.
Forms contexts around knowledge areas
∖ Developers become experts in specific subjects
∖ Features are implemented inside the context: coordination needed is minimized
Example
Context Forming - by areas of expertise
21
# Payment
Authorization
Capture
Refund
# Routing
Logistics
Stock
Store
queue
# Financials
Accounting
Reporting
# Delivery
Shipping options
Shipment
booking
# Catalog
Product
Catalog
Pricebooks

22. NewStore Inc.
Even with context/team alignment, some features are still cross cutting
∖ Use people with cross cutting knowledge and cross cutting relationships
Example: Gift wrapping
Context Feature vs. Cross Cutting Feature
22
# Payment
Authorization
Capture
Refund
# Routing
Logistics
Stock
Store
queue
# Accounting
Reporting
Taxation
# Delivery
Shipping options
Shipment
booking
# Catalog
Product
Catalog
Pricebooks

23. NewStore Inc.
Relationships
∖ Partnership
∖ Shared Kernel
○ Not so valid for Microservices (unless you’re talking about shared models)
∖ Customer / Supplier
∖ Anti-Corruption Layer
∖ Open Host Service
∖ Published Language
∖ Conformist
Example
JSON Schema definitions negotiations between teams - RPC and Events
Antipattern
∖ Separate Ways
∖ Big Ball of Mud
Context Mapping
23

24. NewStore Inc.
Object that has identity and a lifetime
∖ Control the identity generation (vs. using an external)
∖ Unique enough (e.g. UUID4) - low risk of collision
∖ Intention revealing interfaces
Example
∖ Person
Antipatterns
∖ Anemic model
Entities
24

25. NewStore Inc.
Entities - Example
25

26. NewStore Inc.
Immutable. Attribute of an Entity.
∖ If has identity it is not controlled by this aggregate.
∖ Put data that only make sense as a whole together - ex.: Weight (amount, unit)
∖ Know which data you control in your service
∖ You’ll store differently (e.g. JSONB or normalized)
∖ Allows you to create nice helpers around them
Example
∖ Address (in Address Book vs. in an Order) & Product (in Catalog vs. in an Order)
∖ Price (amount, currency) & Weight (amount, unit)
Value Objects
26

27. NewStore Inc.
Value Objects - Example
27

28. NewStore Inc.
Value Objects - Example
28

29. NewStore Inc.
Transaction boundaries for entity updating
∖ How to draw boundaries - part of the data you own
∖ Everything else is just a value object
∖ Choose an entity root and let clients use only that
Antipatterns
∖ Data donkey: exposing data from a different model
∖ The web of relationships
∖ Huge aggregate:
Aggregates
29

30. NewStore Inc.
Creation of data needs specialized handling
Know which type of data you’re dealing with beforehand:
∖ Entities - have identity and a lifecycle
∖ Value Objects - immutable and only makes sense as whole, not in parts
Your methods should describe what you do without needing to reveal how:
∖ Intention revealing interfaces
Gang of Four patterns that have a DDD-twist:
∖ Aggregates - transaction boundaries of data manipulation
∖ Factories - create specialized builders of consistent objects for specific use cases
∖ Repositories - treat persisted object as in-memory collections
∖ Adapters - isolate input and output of data from your service
Lifecycle of a Domain Object
30

31. NewStore Inc.
Objects should be created in a consistent state
∖ Create specialized functions / class methods that instantiate models and handles
initialization from start to finish
∖ All invariants should be asserted
∖ Adapters can be coded as Factories, converting from different representational
formats (Product.create_from_event)
Antipatterns
∖ Create empty object and pass it around,
changing it bit by bit
Factories
31

32. NewStore Inc.
Data in, data out
∖ In: Translate data from external models to your
internal representation
∖ Out: Create a easily consumable model for clients
Be conservative in what you do, be liberal in what you accept
from others - Postel’s Law
Antipatterns
∖ One model fits all: serialization, database, internal
model
○ Relational database impedance mismatch
∖ Expose your entire model
Adapters
32

33. NewStore Inc.
Factories & Adapters - example
33

34. NewStore Inc.
Handling persistence as a in-memory collection
∖ Creates a layer of protection between the API layer, the domain layer and the
persistence layer
∖ Makes the actual persistence layer interchangeable
∖ Convenience for access
Antipatterns
∖ Mix-up layers
Repositories
34

35. NewStore Inc.
Model things that happen in the system as Domain Events
∖ Listen for phrases like: “when X happens, I need information from Y to do Z”
∖ Observe & React vs. Command & Control
∖ Name them with names in the past
∖ Use the ubiquitous language
∖ Enables publish / subscribe (in memory / database / queue / bus) [Observer Pattern]
Business rules Examples
∖ “When payment is authorized, I should route an order to be fulfilled by a store”
∖ Solution:
○ Listen for Checkout.confirmed
○ Listen for payment authorization
○ Act when you have both data
Antipatterns
∖ RPC Machine Gun
Domain Events
35

36. NewStore Inc.
Domain Events - Example
36

37. NewStore Inc.
Making pluggable designs
∖ Easy targets: Integration with 3rd Party services
○ Distill your usage of the API by what are your intentions with it
Examples
Shipment providers - stages of development:
∖ Part of the fulfillment service
∖ One service that only knows one provider
∖ Multiple services, each with its own implementation
∖ Shipment API: abstract, expose through HTTP and place it in the DMZ
Antipatterns
∖ Service that knows it all
∖ Too early abstraction
Supple Design
37

38. NewStore Inc.
Supple Design - Example
38

39. NewStore Inc.
Architecture in DDD
39

40. NewStore Inc.
Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley 2004.
Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented
software. Reading, MA: Addison Wesley.
Oberdi, Obi. Domain Driven Design Refcard, Dzone 2016.
Vernon, Vaughn. Implementing Domain-Driven Design, Addison-Wesley 2004.
References
40

41. NewStore Inc.
The usual, only better
∖ Customizable working equipment (monitor type, Linux or Mac)
∖ Catered breakfast and lunch during the week
∖ 7 types of mixed nuts and 6 types of cereal for all day fueling
∖ Espresso machines for delicious crema-full caffeine injections
∖ Endless soda and beer for sugar breaks and socializing
∖ Spacious Berlin office along the Spree bank
∖ Townhall for employee gatherings and pizza parties
∖ 4 tennis tables & ongoing competitive tournaments
NewStore - the perks
41

42. NewStore Inc.
The Perks without a good working environment means nothing
∖ Innovation
○ Working with awesome people - huge potential for learning
○ Meetups
○ Training budget
∖ Shared success
○ Onboarding process: takes care of your visa process
○ Respect for the worker: self-organization
○ Flat hierarchies - Open collaboration
○ Unmeetings + Townhall
NewStore - the human factor
42

43. NewStore Inc.
Thank you!
43
Bernardo Torres
btorres@newstore.com
https://www.newstore.com/