# 6. Single field address model
Date: 2020-05-21
Driver: Wisen Tanasa
# Status
Accepted
# Context
We are required to show building address and Google maps URL when we're sending emails to seekers and providers. All of these data have been gathered manually in a spreadsheet and were retrieved from Google Maps.
As our web application need to work globally from the root domain, the way we model the address must work globally. There are 2 models that were being considered:
- Use a single string that represents the entire building address. Example:
50 Liverpool St, London EC2M 7PY - Separate every address parts into separate fields, like
country,city, etc.
Option 1 will not require deep modelling as it's just a comma separated string. This string is preformatted and retrieved from Google, hence there will no be complexity in formatting the adddress. This option however will pose a limitation when we want to query an address part. For example, how do we know the postcode of a particular building?
Option 2 will provide a better flexibility in how we query an address part. The
downside of this option is we will need to make sure that it works globally. Not
every country will have a county address part. This is what we have
modelled
for Option 2:
Eventhough the above model would work globally, but we will still lose the
granularity of the address data like county, neighbourhood, region, or
floor.
On top of modelling the address, we will also need to store the Google maps URL.
# Decision
Due to the nature of our tight dependency to Google Maps, we have decided to go
with Option 1. The single string model is how Google has been returning the data
from the placedetails API and the data that we have gathered so far. We are
conforming to their model. We will also introduce a new bounded context:
Location as we don't want to dirty our Inventory bounded context with Google
Maps URL data.
# Consequences
The two address models are actually not mutually exclusive. The model presented
in Option 2 is a model that we should adopt in the Inventory. We will
introduce this model when we are able to let providers enter their own address
data. This data will then be able ingested into the Location where we will
retrieve the more accurate Geo Location, Google Maps URL, etc.
By leveraging the display of address with Google maps formatted address, we will reduce the cost of localising our address in the future. Even though the address data that we capture are agnostic of its country, the way the address should be presented to our users vary per country. For example in Japan, the street name is the last part of the address:
- Google formatted address:
4 Chome-2-8 Shibakoen, Minato City, Tokyo 105-0011, Japan - Google formatted address when Japanese language is used:
日本、〒105-0011 東京都港区芝公園４丁目２−８
The difficulty with this model is when we need to query or show just an address part, like postcode, as this information will not be available in the single string model. This problem will be mitigated once we are retrieving Google place details automatically, where more address parts information will be available there.