- Make the console app more of an adapter with better test suite, non-acceptance-test-stuff differ
- Fix adapter conversion code as its wrong in some spots, should be abstracted to view somehow
- Fix MVC done
- Fix Blazor differ, maybe delete altogether
- Fix API done
- Fix Console done
- Add authentication for roles use case Doing this
- Implement authentication in WebApi and WebApplication done
- Implement Manager Role
- Implement Employee Role done
- Add use case Accounting Clerk/Controller/CFO/Manager/Employee Roles
- Add use case list all reports + view
- Add use case sort/filter list of reports
- Add use case for showing manager all over-expensed items
- When is it better to return the domain object rather than a string? I would think when you don't own that code?
- I do map multiple aggregate Id's to a list, so that I can retrieve by aggregate, this seems "fine"?
- The entire adapter could be in an external codebase. For a Mobile App, I would have the Mobile API in this codebase, but then the swift/kotlin app would be in a different codebase?
- The adapter could also be used to produce multiple Database-specific tasks, think creating a CSV Report of Expense Reports
- We could also import in from a 3rd/2nd party application ExpenseReports, to be shown to the user here. How does our code change in these scenarios?
- "DomainServices" are actually just interfaces/ports. Should the Adapter ExpenseService go in that layer, or remain in the adapter layer and get "plugged into" out layers
- Blazor uses sockets, how would I test that through the client?
- The out adapter is very interesting as there are Expense and ExpenseReport objects that map to a DB
Implement Employee Role:
- An employee can submit his expense reports done
- An employee can add expenses to his expense reports done
- An employee can view his expense report done
- An employee has access to only his expense report list done
- An employee's expense report are not approved done