Before we begin . . .

Go to the "voting" table we've setup at the back.
 

Vote on whether you've tried to introduce DDD to your company and rate how successful it's been.

Introducing DDD to your Company

@ie_ddd

@barryosull

@daraghoshea

https://www.dddireland.org

https://www.barryosull.com

https://www.daraghoshea.com

Sponsored by: 

Introducing DDD to your company.

The Meetup:

  1. Why introduce DDD?
  2. How to introduce it
  3. Dos and Donts
  4. Three Techniques
  5. Group Discussion
  6. Networking

Meetup Structure

Why introduce DDD?

Let's discuss why you want to introduce it.

What value will it bring and why?

 

(10 mins)

Consistent language between dev & business

Better Software

Strategic alignment 

Architecture that helps build solutions

How to introduce it?

Dos:

  1. Focus on the problems stemming from not using DDD
  2. Demonstrate that DDD can fix these problems
  3. Use the businesses language
  4. Empathise

​Donts:

  1. Focus on the name and its technical aspects
  2. Hype them up about how technically cool it is
  3. Evangelicise about it out of the blue

You're selling the concept.

So sell it!

Don't Just Talk

Demonstrate Value

Three known techniques

1. Event Storming

Go into a room and event storm a new feature with the product owner and/or domain experts.

1. Event Storming Tips

  1. Focus on events and constraints
  2. Ask what things are called, be curious and listen
  3. Don't use technical language
  4. Don't hype up the event storming concepts, just do it!
  5. Iterate on the solution space
  6. Let business owners critique and break models
  7. Make business owners aware of complexity/cost

2. Talk with the domain experts

2. Talk with the domain experts tips

  1. Use their language in conversations, not yours
  2. When a feature request is missing concepts, don't make up language among yourselves, reach out and ask them
  3. Rename code concepts to match their language
  4. Get them in a room, draw your understanding on a whiteboard, get them to confirm/deny
  5. The PM/PO may not be the domain expert

3. Separate Domain Code from Infra Code

3. Separate Domain Code from Infra Code Tips

  1. Reduces noise, allows you to begin to see the domain
  2. Ask business owners what things are called
  3. Allows you to write tests for domain constraints
  4. Allows you to test infra independently
  5. Can be done piece by piece
  6. Requires buy in from developers/architects

Discussion

How could you introduce DDD to your company?

  1. Break into teams of 4
  2. Discuss various ways to do introduce DDD
  3. After 20mins, present your ideas to the group

Next meetup

Lightning Talks: Real world DDD Experiences

Modelling Constraints: Defining our systems

or

Which do you prefer?

Made with Slides.com