👉You can use CRUD in a large app
You can start with CRUD at the beginning.
That's what frameworks like Rails recommend.
At the start it's actually faster. It's OK.
But later (once you hit market validation?), it's no longer true.
Most of the crucial business logic needs to be extracted. There's no easy way to keep CRUDs compatible with business logic without a ton of hacks and nested IF statements which no one wants to touch.
→ You need to draw the boundary between the application layer and the domain layer.
→ You need to encapsulate business areas with contexts.
→ Your pricing logic should be separated from Inventory logic.
→ Your Inventory logic should be separated from the Ordering logic.
We exactly know how to do it. It's easier than it sounds. After you know it, you will laugh at all the CRUD/framework approaches.
👉Event-driven requires microservices
It's true that many projects which went for event-driven architecture are based on microservices. They use Kafka or RabbitMQ for publishing the events over the network.
But it's not really required.
Microservices bring some benefits:
Resume-driven developement can gain from using different languages in different parts of the system. They offer some scalability. But 99.9% of our projects don't need microservices.
→ In fact, they go slower with them.
Their budgets are bigger.
More people are needed, more infrastructure, more communication, more processes.
The truth is : Event-driven architecture is a fantastic way to decouple your application AND it doesn't require microservices.
Your decoupled modules can live in the same memory, the same process.
→ We go for event-driven, not because of scalability, but because of the simplicity it brings.I can help you understand the true elegance of a codebase which relies on well designed events.
→ I can help you choose when to go for event sourcing (and how it differs from event-driven). I will help you decide when to use small events and when to go for big events...
👉Your client doesn't know what they want
It's true that your client if often lost.
They change their mind too often.
They are impatient.
They don't think about details.
In Poland we have a saying "do tanga trzeba dwojga" - It takes two to tango.
That's why they need us.
They came to us, asking for help (with the project).
They depend on us.
It's our big responsibility not to let them down.
It's our responsibility to teach them how to communicate with us.
It's our responsibility to proactively let them know what is possible and what is not. We need to teach them to understand the system - so that they have a similar gut feeling as we do on which changes are hard.
If we don't help them - they will be lost.
They will have no idea what they really want. It's up to us.
I can help you learn how to build the trust with the client.
That's why we merge all of our courses and materials to launch...