API-34441 introduce POA request models

[nihil2501]

At this point it has become apparent that there is a good place between the BGS transport layer and the domain logic (service) layer for a persistence (or model) layer. In this PR (combined with a following PR) we have:

• POA request
  • search
  • find (actually just used by decision:find since it's a one-to-one relationship)
  • load (just used by search and load but isolates how the data maps between BGS's representation and ours)
• POA request decision
  • update
  • find
  • dump (just used by update but isolates how the data maps between BGS's representation and ours)
  • load (just used by find but isolates how the data maps between BGS's representation and ours)

The clearest example for the niceness of the model layer so far is that POA request find is implemented under the hood with readPOARequestByPtcpntId since there is no way to get a POA request directly by the proc ID (but our representation's ID is a redundant composite key to adapt to BGS).

Right now this model layer only consists of immutable values with Data from Ruby's standard library and then a few functions (e.g. find and update) which are really more like repository functions. In particular, we aren't using anything really big like ActiveModel for stuff like ActiveModel::Dirty dirty tracking or validations. In my opinion these encourage a not great architecture that tends to conflate domain logic and persistence logic which Rails is known for.

I plan to take another look at the division between POA request search as it exists in the service and model layer to see if anything can be more direct in that code.

[github-actions]

1 Error

🚫

This PR changes 661 LoC (not counting whitespace/newlines). In order to ensure each PR receives the proper attention it deserves, those exceeding 500 will not be reviewed, nor will they be allowed to merge. Please break this PR up into smaller ones. If you have reason to believe that this PR should be granted an exception, please see the Submitting pull requests for approval - FAQ. File Summary Files modules/claims_api/app/controllers/claims_api/v2/blueprints/power_of_attorney_request_blueprint.rb (+8/-10) modules/claims_api/app/controllers/claims_api/v2/{power_of_attorney_request => power_of_attorney_requests}/base_controller.rb (+1/-1) modules/claims_api/app/controllers/claims_api/v2/{power_of_attorney_request => power_of_attorney_requests}/decisions_controller.rb (+3/-3) modules/claims_api/app/controllers/claims_api/v2/power_of_attorney_requests_controller.rb (+1/-1) modules/claims_api/app/models/claims_api/power_of_attorney_request.rb (+42/-0) modules/claims_api/app/models/claims_api/power_of_attorney_request/decision.rb (+30/-0) modules/claims_api/app/models/claims_api/power_of_attorney_request/load.rb (+132/-0) modules/claims_api/app/models/claims_api/power_of_attorney_request/searching.rb (+106/-0) modules/claims_api/app/services/claims_api/power_of_attorney_request_service/poa_request.rb (+0/-183) modules/claims_api/app/services/claims_api/power_of_attorney_request_service/search.rb (+3/-72) modules/claims_api/app/services/claims_api/power_of_attorney_request_service/search/query.rb (+18/-45) modules/claims_api/config/routes.rb (+1/-1) Note: We exclude files matching the following when considering PR size: *.csv, *.json, *.tsv, *.txt, Gemfile.lock, app/swagger, modules/mobile/docs, spec/fixtures/, spec/support/vcr_cassettes/, modules/mobile/spec/support/vcr_cassettes/, db/seeds, modules/vaos/app/docs, modules/meb_api/app/docs, modules/appeals_api/app/swagger/, *.bru Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger

[FonzMP]