What is Serverless?
Serverless computing a method of providing backend services on an as-used basis. As Developers working on Serverless we don't have to be concerned about about the infrastructure or code is runs on, we don't even have to worry about the security of our backend services, of course we still have to build fool proof programs.
Advantages of using Serverless. There are many advantages of going Serverless some of which are fast delivery time, Reduced infrastructural maintenance ,Scalability is handled by our provider, and we only pay for what we use.
What is Domain Driven Design (DDD)?
It is set of rules that enable us to make the right decisions, a set of principles and schemes aimed at creating optimal systems of objects. It allows us to significantly speed up the software design process in an unfamiliar domain.
Last but not least it enables us to write business logic that is independent of its infrastructure, this makes it easier for us to migrate away from one infrastructure to another.
Why Should I care about the Architecture ?
Software Grows Quickly. Change is a constant in Software and distributed architecture can also be a huge ball of mud. There solution to this is we need to be disciplined and apply principles ,a few layers and some rules to our work. BAD software is Costly. Bad software results in hard to maintain software, increase in defects as features get added .and low test coverage.
A good Software Design allows a steady growth in a software products without compromising any expect of the domain.
But how do You come up with a good software Design ? DDD to the rescue. Domain Driven Design allows you to glue the Business domain ,users needs ,and software engineering strategies together to bring about viable long lasting and easy to adapt to change software.
Where to get Started ? First of we need to understand who are our users, their needs then we have to connect all the components that make it possible to bring solutions to our users needs. The aim is to only focus on our users needs and understanding the problem domain first. To do this we need to collaborate a lot with out domain experts ,the more we gain domain knowledge as developers we end up coming up with an ubiquitous language(a common language between domain expects and developers).To understand the domain very well we make use of DDD patterns and practices, the Strategic Design and the Tactical Design.
Strategic Design - is divided into two spheres ,our problem space and our solution solution. in our problem space we build our understanding of the business domain and we discover our subdomains. Then in our solutions space, we breakdown our solutions into modular activities (bounded contexts) then we start mapping interaction patterns between context maps.
Tactical Design - Refers to Architecting a solution fitting the problem as closely as possible this solution should provide building blocks to implement the domain models.
Getting started with in strategic design,
Our Business Problem domain has to be subdivided into three subdomains
Core subdomain
Supporting Subdomain
Generic subdomain
Core Subdomain - This the core of our product, the cannot be a product with these components. They provide a competitive advantage, they are complex and are made of many different and connected parts , they are normally referred to as Aggregates, they can change often. They do not have external dependencies.
Supporting Subdomain - These are extensions to the core domain they make the core better ,that doesn't mean the system can't exist without them but they are vital to making the system functional. They normally do not have a competitive advantage and they do not change often.
Generic Subdomain - These features are of no competitive advantage and are a norm among software and user expectations , they are normally very complex and they do not change ,since they are are in most cases expected to be part of our product we can outsource these , e.g. Using Cognito for authentication.
Getting started with a real real world example.
We have been tasked with creating a software that will allow users to log issues in their community, and have the right people attend to those issues. Lets focus on our users needs.
Regular users (loggers):
They need to log to be able to submit issues.
They need to view their submitted issues and kept up-to date with their issue changes
Admin Users:
Admin users need to able to manage those issues (edit, change the issue progress and also cancel false issues).
Assign the right people to manage those issues.
Manage users
Manage roles and permissions.
Communicate with loggers and issue authorities
Authorities (Departments)
Able Evaluate and resolve issues.
...You get the idea...
Once we have understanding of our users needs we break our problem domain and discover subdomains and bounding contexts. And start building our Business Models
With the help of Serverless we can physical boundary contexts, each process will have deployed and contained
Do remember that Architectural patterns can differ per Bounded Context.
The wonders of serverless :
To keep the article short we are just going to focus on the Hexagonal Architecture.
Hexagonal Architecture in Serverless
But How do you represent this in code ?
BUT I want to use functions ?
Data Storage using AWS DynamoDb.
The Business Logic implementation?
Our Aggregates
Getting to our Application Service
The Repository
We start of with a contract interface then we have create an implementation of DynamoDb Repository (our Adaptor) implement it.
I hope you enjoyed the article. cheers...🤗🤗