Play 3: Be Informed by Multiple Best of Breed Software Design Strategies

Offer multiple design strategies for every aspect of problem

A software design strategy is a discipline that helps organizations identify the most important questions a project should address. Multiple design strategies will serve to broaden this list because they approach the problem from different perspectives. Each strategy informs specific aspects of the problem. Depending on the size and scope of the transformation, several software design strategies used in combination may be the best approach to reveal the most complete scoping of the effort. 

Human-centered design

Human-centered design is about building a strong and empathetic understanding with the users you’re designing for, while generating ideas, building quick prototypes, and converging on user experience patterns cooperatively with your audience. Human Centered Design is enabled by both data analytics and informed more broadly by User Experience data. For a more detailed understanding of how to ensure user experience drives your designs, consult the User Experience Playbook (coming soon).

---

 

Human-centered design principles

Understand the Root Problems

• Leverage customer intelligence data if it exists
• Gather real world observations of actual use through audience studies 
• Understand legal, economic, cultural and social variables
• Identify issues and dig into failure modes. Ask “why?”
   

Follow a people-centered approach

• Observe individuals deliberately while they do their routine tasks
• Consider all the people who are involved
• Organize responsibilities into roles
   

Implement a task-centered systems approach

• Design should focus on the entire task being considered, not just individual components 
• Provide essential analyses and approaches, ensuring those most affected by issues are most involved in the process 
• Understand that most complications result from the interrelationships between components 
• Develop end-to-end activity workflows
   

Rapid iterative prototyping and testing

• Expect initial approaches for improvement to be imperfect or incomplete 
• Validate in small doses and learning through rapid short experiments
• Rethink and repeat experiments until result is good enough for deployment 
   

Domain-Driven Design

A design approach where the business domain is conceptualized and abstracted in software independently of the lower-level implementation that makes the system work. Domain Driven Design separates a business problem into a collection of independent Bounded Contexts. Each context has a domain model, which in software fully encapsulates the data it needs, the business operations it needs to perform, and the ubiquitous language used to describe the components within each context.  

Domain-Driven Design is a preferred tool for determining and separating discrete business capabilities and defining the interfaces and roles needed to ensure those services can combine to form loosely coupled micro-service-based applications. Convergence on a ubiquitous language that is shared by designers, developers and stakeholders sets the stage for defining and documenting a discrete business capability in terms of a bounded context.  Communicating effectively with stakeholders without being overly technical is one of the greatest benefits that Domain-Driven Design has to offer.  

---

 

Domain-Driven Design benefits

1. Simplify complexity

Domain-Driven Design was designed to simplify complexity and create a clear distinction between the interfaces that are needed for a business capability and the underlying data definition. Domain Driven Design focuses on ensuring that separate business capabilities remain independent from one another through loose coupling. It does this by formalizing the separation of discrete business capabilities into separate Bounded Contexts each with its own Domain Model.
 

2. Design for loose coupling

Each bounded context owns its own business logic, orchestration, transformation and deployment. Changes in one domain model do not adversely affect other domain models. Bounded contexts retain independence and remain loosely coupled by relying on an anti-corruption layer, which is responsible for translating the objects given by the upstream into its own models. The anti-corruption layer will guarantee the integrity of the downstream bounded context by keeping it completely ignorant of any foreign concepts. By building in separation of data interface and underlying data implementation, the lower the coupling.
 

3. Effectively Communicate

Capabilities defined in terms of Domain-Driven Design are intended to be understandable by the entire project team. Domain-Driven Design provides principles and patterns to solve difficult problems and is an effective way for software developers to write clear and testable code. Stakeholders and business users are typically not interested in how the code works or how the software is built, but rather in understanding the business problem and the proposed solution described in business terms.   

Convergence on a ubiquitous language that is shared by designers, developers and stakeholders sets the stage for defining and documenting a discrete business capability in terms of a bounded context.  Communicating effectively with stakeholders without being extremely technical is one of the greatest benefits Domain-Driven Design has to offer. 

---

How to incorporate Domain-Driven Design into an application

1. Divide the software problem landscape into Bounded Contexts with independent Domain Models and separate Ubiquitous Languages.

2. Determine which Bounded Contexts need to communicate with one another. For each of these perform a context mapping, the Domain-Driven Design tool that allows you to identify the relationship between bounded contexts and the relationship between the teams that are responsible for them.

3. Build context maps around the notion of domain events, which are simply statements of facts that have happened on the upstream side of the mapping. If bounded contexts communicate via fact-based messaging, then they aren’t coupled.

4. Domain-Driven Design distinguishes between entities and value objects. An entity has persistent and potentially changing identity making it hard to manage in a distributed system. A Value Object is simply a snapshot of state that is not changeable and is distinguishable only by the values of its properties.