Let's say that I have a list of financial transactions that I need to read in from the file. I want to make the best guess I can at what account should be credited/debited based on the transaction memo compared to past transactions.

For example, if Wal-Mart was used with 'Shopping' then if a transaction that gets read in from the file with Wal-Mart as the description should show 'Shopping'. If there cannot be a match found, then the application should make the best guess and get feedback from the user. If there is not a best match then the user should be asked which account makes most sense.

To me, there is a lot of interaction with the user so it would make sense that this should all live in the UI layer. Once all the transactions are paired with accounts, then it should be sent to the Application Service layer to be saved.

Right now I'm just using a CLI, so I could inject an object that inherits from a 'Presenter' interface that the Application Service uses; however, this will not work when I get rid of the CLI and want to use a REST API around the Application Service layer.

Does it make sense to just include all this logic in the UI layer?

1 Answer 1


No, that logic does not belong in the UI layer.

The UI layer should only be concerned with how information is presented to the user and how the user can give input to the system. You don't want to be re-implementing all that logic for matching transactions to accounts when you decide to change your UI concept (for example from a CLI to a GUI or to a speech-based user interface).

It is entirely appropriate if your application (or even domain) layer indicates to the UI layer that it needs an answer from the user on a particular question before it can proceed with the processing.

  • This makes sense to me; however, how would it be implemented? Right now I’m using multiple callbacks to prompt the user. This will not work with a REST API, however.
    – keelerjr12
    Apr 17, 2021 at 11:27
  • @keelerjr12, it can also work with a REST API, if the API waits with giving a response until the application layer has indicated if more information is needed. That request for extra information could then be included in the response given by the REST API. Apr 17, 2021 at 11:58
  • Got it. So you could pass back 2-3 requests with the need for more info? For example: client sends file to API to be parsed, API returns list of transactions that could not be added with a suggestion for a paired account, then the client confirms or changes the account, and back & forth, etc.
    – keelerjr12
    Apr 17, 2021 at 12:12
  • @keelerjr12, indeed. that is how it can work. Apr 17, 2021 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.