Day 4 Main conference day 1

Key note by Nick Tune: Dissecting bounded context

Key takeaways

• The domain driven design community haven’t landed the idea of what the DNA of a Context is yet.
• You will not be able to create very good context models if you do not understand the business model. We are making tradeoffs all the time, and it is important to know what needs of the business we are trying to address.
• Context boundaries, coupling and type of relationships between contexts are ever changing with the changes of requirements in the business.

• When you do a talk link to the slides on the first slide.

• The domain driven design community haven’t landed the idea of what the DNA of a Context is yet.
• You will not be able to create a very good context model if you do not understand the business model. We are making tradeoffs all the time, and it is important to know what needs of the business we are trying to address.
• Context boundaries, coupling and type of relationships between contexts are ever changing with the changes in what requirements are needed in the business.
• When you organize a seminar link it to the slides on the first slide.

Hands on workshop lab by Tobias Goeschel: Test driving your domain core

The workshop went off track because we spent most of our time getting the technology to work instead of doing the objective of the exercises. This meant that there was almost no back about the Tobias thoughts about behavior driven development.

Key takeaways

• The behavior driven testing style we are using today is very aligned with the example given.
• Tobias stated that the behavior tests should be written with whoever owns the business the system you are writing on supports.
• Your behavioral test should be operating on API’s/fixtures/Interfaces not aggregates themselves.

Talk by Elisabeth Hocke: A story of mob programming, testing and everything

Key takeaways

• When 2 solutions to a problem is proposed, try both, start with the suggestion from the most junior person or the least standard solution.
• Build energy around ideas by using “yes, and…” instead of challenging the ideas directly. We trying to build a product together not win arguments.
• Invite people from other teams into the mob programming you do in your team, this is a great way of sharing knowledge and getting closer to people in other departments.
• Have the physical environment set up and prepare as much as you can beforehand to insure the success of the programming session.Some great insights can be found here.
• Start all mob sessions with why you are doing it.
• End all mob sessions with a micro retrospective.
• Have a designated navigator at the first sessions you do.
• Mobbing is a great tool for exploring an area where there isn’t much existing knowledge in the team.

Random impressions

When standing and discussing things in a group make the shape of Packman, so there is always room for a extra person to join the conversation.