# Write Change-Resilient Code With Domain Objects

DevFeed: [Write Change-Resilient Code With Domain Objects](<https://devfeed.tech/articles/write-change-resilient-code-with-domain-objects-23860.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2024/09/write-change-resilient-code-with-domain.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2024-09-04T12:56:00Z

Content type: tutorial

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [maintenance](<https://devfeed.tech/topics/maintenance.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>)

Tags: [amy-fu](<https://devfeed.tech/tags/amy-fu.md>), [code](<https://devfeed.tech/tags/code.md>), [code-health](<https://devfeed.tech/tags/code-health.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [tott](<https://devfeed.tech/tags/tott.md>), [writing-code](<https://devfeed.tech/tags/writing-code.md>)

## AI overview

This Google Code Health article explains how domain objects--classes and interfaces that model a product's fundamental ideas--can make code more resilient to changing requirements. A gPizza example shows how modeling shared concepts can reduce the maintenance burden caused by adding requirement-specific methods.

## Source excerpt

This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office. By Amy Fu Although a product's requirements can change often, its fundamental ideas usually change slowly. This leads to an interesting insight: if we write code that matches the fundamental ideas of the product, it will be more likely to survive future product changes. Domain objects are building blocks (such as classes and interfaces) in our code that match the fundamental ideas of the product. Instead of writing code to match the desired behavior for the product's requirements ("configure text to be white"), we match the underlying idea ("text color settings"). For example, imagine you're part of the gPizza team, which sells tasty, fresh pizzas to feed hungry Googlers. Due to popular demand, your team has decided to add a delivery service. Without domain objects, the quickest path to pizza delivery is to simply create a deliverPizza method: public class DeliveryService { public void deliverPizza(List<Pizza> pizzas) { ... } } Although this works well at first, what happens if gPizza expands its offerings to other foods? You could add a new method: public void deliverWithDrinks(List<Pizza> pizzas, List<Drink> drinks) { ... } But as your list of requirements grows (snacks, sweets, etc.), you'll be stuck adding more and more methods. How can you change your initial implementation to avoid this continued maintenance burden? You could add a domain object that models the product's ideas, instead of its requirements: A use case is a specific behavior that helps the product satisfy its business requirements. (In this case, "Deliver pizzas so we make more money".) A domain object represents a common idea that is shared by several similar use cases. To identify the appropriate domain object, ask yourself: What related use cases does the produc