Model the Business Domain
Terms, concepts and capabilities of the business should be reflected in the way we write, structure and deploy our code and systems.
Using a common language throughout the team to describe business concepts and processes allows for a common understanding. Misunderstandings that lead to defects are easier to identify because the language that is used allows non-technical stakeholders to understand and correct it.
Structuring component systems to reflect and influence the organisational structure will allow for a more agile and responsive delivery as teams and systems are more closely aligned to the customer value that they provide.
- We will need to take advantage of Conway's Law (where software reflects the organisation that built it) to validate and influence both the systems we write and how we structure the organisation.
- A system should have a product/business owner identified so they can encourage and nuture a sense of ownership for future change and support. It will become their 'problem' if it breaks or requires changes to be made
- Where packages have their own model and terminology, we may need to create abstraction layers to map to the business model
Points for discussion
- Does it use DDD (Domain driven design)?
- Could a business person understand the language used in your code?
- How well do you own your domain?
- Are there changes not owned by your team?