A very common problem in enterprise software development is related to handling postal addresses. Nearly every country has a particular, and peculiar, way to structure a postal address. This reference is a high-level overview of the problem complete with details for a number of countries. We will attempt to address (no pun intended) this problem by delivering the following:

Design and document your architecture and UI interface. Implementation of any functionality is encouraged by optional. A working implementation is required, and demonstrating it is worth extra credit in the Team Presentation. Web UI and API must be implemented and working, with API methods implemented to use real data from database or files to provide functionality.

• Design a web-based user interface (a form) that can capture a country-specific address format entered by an end user
  • The form must dynamically adjust to capture the address
  • Validation of the address formats and related data must occur in a reasonable time for the user
  • The end user should be able to select data from appropriate user interface elements and not just type everything in free-form
  • Where possible, default values and constrained lists should be presented to the user
• A way for a user to search for a given address based on the country-specific format (name, partial address)
• A way for a user to search across countries to find "matching" addresses and display them in the application
• An API callable via HTTP (curl or postman) because we might want to sell access to this application
  • Documentation for the API, preferably available alongside the API itself (think swagger / OpenAPI)

An address search should return a result to the end user in < 75ms and should support at least 1000 concurrent requests (read, write, and search). Your "database" should be seeded with a large number of addresses of various formats spread across the countries on a per-capita basis (or approximately based on number of residents in each country).You are responsible for writing the code that seeds your database, and you can decide if you exercise your API to do so or if you want to "go around" your API and write the data in some other way.

Astute readers will have noticed that this list of requirements is woefully inadequate. That is, I haven't provided (completely) sufficient requirements for the project. That means your team will need to discover additional requirements. You may do this by asking me in class or preferably on MS Teams; you may ask other teams what they've done (only for requirements); and, you may make assumptions about requirements (in which case you must document your assumptions, the reasons you made them, and alternatives investigated).

What your team needs to deliver

• A high-level architecture overview (one-pager) explaining and justifying your architecture style / pattern choice down to the component level (include any assumptions you are making.)
• A preliminary design document explaining how your team will create the solution using your style / pattern choice, including static CCD models and high-level coverage of any APIs and data interchange. (CCD = Components, Connectors, Data elements. See the Fielding paper in Reading Materials for lots of information on modeling and communicating architecture.)
• A detailed design document covering design patterns, algorithms, technologies, and trade-offs. To include detailed API documentation and any internal documentation.
• Implementation code for all components in your system. (API, UI, and any other code you wrote)
• All submissions must be completed and made available to me before your Team Presentation. That is, I want to see the final presentation materials and implementation (code for web UI and API methods, database contents, etc.) before your Team presentation. This is so I can preview your presentation and possibly provide any last minute input.