Good intentions…
Lets imagine you’re a developer at a company that sells widgets. There is lots of widgets of different types. You have suppliers, you have clients, you have a sales department, accounting, human resources, the works.
You use Oracle, SQL Server, or another enterprise DB vendor because that makes the most sense. You need transactions, stored procedures, you need a complete relational database to model your company on. You can’t afford any errors and you must use transactions to prevent them.
Of course you are now married to your database and your chosen DB vendor. But that is just how things are done.
But…
After this point you can try as hard as you can in your code. The natural tendency will always be towards a monolith. When your data model is a monolith, your code naturally follows the pattern.
It may start out working great, but after years of upgrades and changes, it inevitably starts collapsing under its own weight. Sometimes in particularly bad cases (i.e. government projects) the architecture implodes before it is even deployed. The problem is that you can only design for what you know. The system is built for what the situation is now and you have no idea what the future will be.
The company of course changed, hopefully it grew and started doing more things. It may have made some drastic changes to its core business.
A change in business structure must also require a change in how your software is supporting your business. If you want a nimble business you must also have nimble software that supports it. A monolith cannot be nimble.
An alternative path…
Problems with monoliths is what microservice architecture aims to solve. While many think microservices take things to the other extreme, it all depends on how you implement them. It is up to you to decide how micro you are willing to go. Splitting a large problem into small understandable chunks is how problems in computing are solved.
Microservice architecture data model is to logically have a database-per-service. Realistically this means you can still use a single actual database, but just have microservices work in separate schemas/tables. This is a compromise for medium/small teams so they don’t live in an operations nightmare.
Improve the alternative…
This brings us to why I think the ActorDB way of doing things is worth considering. ActorDB is a distributed database that gives you a choice how micro you are willing to get. It gives users the option to decentralise, keep using SQL, keep using schemas, use JSON fields if you want. But work in an environment that encourages splitting up the problem into smaller workable chunks. Instead of combining them into an ever increasing ever more complicated all encompassing solution.
A real life example how ActorDB encourages splitting the problem into smaller chunks:
We have created a highly secure communication app named Biocoded and ActorDB is a part of this solution. Users can be organized into circles. This means if users A and B are in circle X, they are in each other’s contact list.
Every user is an independent actor (i.e. SQLite database). Initially we had all contacts for a user in his contact table. The problem was what happens when a user leaves or enters a circle. It requires you to update every actor in the circle. This is way too ugly to consider.
The simple solution was to create a new actor type and put the list of users there and there only. The right solution was to split the problem into a smaller chunk.
But ok what about my widgets company…
Use ActorDB as a beneficial constraint. Writing queries to access all actors at the same time is not going to work well. It will force you into a design that may require more thought to implement initially, but it will force you into a design that is decoupled.
The various areas in your company are actor types. They all have their own schema and actors. Your products are actors. Divide your code into chunks that work on those individual actor types. They can be the same app, they can be entirely different apps. You can have transactions across actors. But it is something to be avoided not encouraged.
Your code follows your data model. A decoupled data model will lead to decoupled code.
http://www.actordb.com/
Written by Sergej Jurecko