Often when someone thinks about software engineering, he gets the recommendation to slice the elephant. E.g., you want to design a nice e-commerce pet shop, you need to cut it into individual slices.
But for me, slicing the elephant sounds quite strange: An elephant in slices is still difficult to handle – even then those slices would be quite large (even if they are smaller than the original elephant). Moreover, the slices belong only to that specific elephant.
You might now be thinking, what is she talking about? I’m talking about software design. Even if you slice the elephant and create some n-tier software, you end up with a monolith. Even if you use interfaces, those interfaces only work with your specific case of software. Other parts of your infrastructure can’t use your services, because they are specific to your design. This in turn means that, if you only have slices of one specific elephant, when you put them together, you will never get a mouse or even different elephant.
But if you design specific functions for your e-commerce shop, such as Search or Detail View, you might be able to use these nicely not only in the pet shop but reuse them in a virtual art museum as well.
So, you create a paradise with independent parts – trees with fruits, monkeys and donkeys, flowers and grass, cats and mice, sheep and goats, the snake 🙂 and so on. Each of the plants and animals are able to exist on their own, even though they interact with each other. The goats can eat the grass or the monkeys eat the fruits from the trees. But since it’s paradise, the cats don’t eat the mice 🙂 . We want to design services, which can work independently, but can also work together.
Therefore, don’t slice the elephant – create a paradise, and maybe even the elephant can live there as well 🙂 .