The last layer is where the service abstractions are written. For maximum code reuse, these are likely to be libraries that you can reuse in other functions where you need to interact with the same service. For example, you might write a library that interacts with DynamoDB tables in a way that is specific to your problem domain. This is also the place to write bespoke integrations with other systems that the function might interact with, such as a CRM system or SOAP-based service.

So, where does the business logic go? Well, that really depends on the language you're using, but, as a guide, it can exist anywhere outside of the layers we've talked about here. In Node.js, we might use an exportable function that uses the configuration from the controller and leverages functionality from the service layer. In Java, our implementation would likely be in the form of a class.

This section was all about making you aware of the more advanced factors of structuring Lambda functions. This information will be more relevant to you if you are developing serverless applications that are more complex, but there are some good nuggets of best practice to take away.

The next section will explain another characteristic of Lambda functions, that is, container reuse, and how to use this to your advantage.