Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
I would like to add that it depends of the context of your software. I think it's not necessarily needed to bring hexagonal architecture for a CRUD application which will stay CRUD, for example. Let's not forget that all of that bring complexity.
Before using design patterns from DDD (services, aggregates, value objects...), using the strategic methods (Ubiquitous language / recognizing bounded context) are less costly and can show you if you really need to break your monolith.
The problem is not really the monolith, it's the coupled monolith. Reducing coupling, increasing coherence can be done with another monolith (with modules, for example). Microservice can bring a lot of complexity on the network layer, let's not forget that too.
I have added the complexity of hexagonal architecture in this scaffolding as each fork will have its own logic that does not necessarily correspond to a simple CRUD, which will allow me to evolve each one strategically without creating new micro-monolith.
With respect to DDD I totally agree with what you say, I had this strategic process before designing this solution, starting with ubiquitous languge which was a tremendous challenge at the company level to agree on each concept, this process I would like to document to expose and see how to improve.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting article.
I would like to add that it depends of the context of your software. I think it's not necessarily needed to bring hexagonal architecture for a CRUD application which will stay CRUD, for example. Let's not forget that all of that bring complexity.
Before using design patterns from DDD (services, aggregates, value objects...), using the strategic methods (Ubiquitous language / recognizing bounded context) are less costly and can show you if you really need to break your monolith.
The problem is not really the monolith, it's the coupled monolith. Reducing coupling, increasing coherence can be done with another monolith (with modules, for example). Microservice can bring a lot of complexity on the network layer, let's not forget that too.
Looking forward for your article on DDD.
Thanks Matthieu, nice feedback.
I have added the complexity of hexagonal architecture in this scaffolding as each fork will have its own logic that does not necessarily correspond to a simple CRUD, which will allow me to evolve each one strategically without creating new micro-monolith.
With respect to DDD I totally agree with what you say, I had this strategic process before designing this solution, starting with ubiquitous languge which was a tremendous challenge at the company level to agree on each concept, this process I would like to document to expose and see how to improve.