Complexity is the primary enemy of software design and architecture. The primary job of a software architect is to remove, reduce, or manage complexity in that order. But what if the problem space itself is complex? How do you do that? What does it even mean? What is complexity, anyway?
There are actually multiple types of software complexity, and each type requires a different approach.
Developers use the word "abstraction" regularly, yet there is limited understanding of what it means. In a broader sense, abstraction has been overshadowed by its use in some languages to denote a method or class that will be overwritten later, as well as the phrase "use abstraction." is understood to mean "write an abstract class.".
Abstraction is one of the most important techniques for achieving decoupling and stabilizing your public interfaces at any level.
There are many ways to create a Modulith, and I will introduce you to one of them. The important parts that we will discuss are: Application layer, Business modules, Facades / Repositories, Event bus/broker, CQ Router and Utilities.
Understanding the roles of these parts is essential to building a code base that won't end up as a "big ball of mud".
The monolithic style has a bad reputation, but it is useful for smaller applications. The problem is not the monolith itself, but rather how it is written.
Why choose a monolith over a distributed architecture, such as microservices? Networking creates its own set of problems. There are benefits, but also costs.
Modular monolith - modulith is the way how to start application.
"You should be loyal to the company, share our goals and align your values with the company's values”. That's not going to happen... Don't get me wrong, I'm not saying "I'm not going to do that," I'm saying it won't happen, it can't happen, it's not possible.
People are not loyal to the company, people are loyal to the people in the company and enjoy the culture created by the people in the company.