After studying some basics about n-layer architecture, I face to a new proyect where my database is an ERP and the way to connect with it is via API calls. I can perform queries to obtain data but the only way to insert and update is using the API.

I have to write two applications, a website and a web service. Obviously I cannot just public my ERP API as webservice because a I need to make some restrictions. I'd like to share most of the code, so I have thought writting two presentation layers, using MVC pattern with their own model each one. Functionality might be different, but having shared procedures.

Since bussines logic is mainly done at ERP level, but I still need to implement very simple restrictions, and that persistance layer is based on an API and not directly to a database, what kind of architecture should I use?

Having a domain layer with that very simple business logic seems to overkill for me, and I dont know how if we should implement a data access layer since I don't really have a typical database. All my thoughts are about creating just one layer for this business and data access, but I'd like to know if this is a common pattern I could read or study about.

P.S: I work in a very little team. I still want to separate concepts and make a clean use of layers, but I don't want too much extra work for such a little team. We all will probably work at every layer.

  • What's your research on GraphQL? Commented Apr 18, 2021 at 9:07
  • If you're talking about my ERP API, that's something out of my control. It's provided by the ERP, all based on XML data and I cannot modify its behaviour. If not, that's just part of presentation layer and it doesn't really matter which technology I use there. Indeed, we will also make a website client with similar features. Commented Apr 18, 2021 at 16:59


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.