My Learning To Pick the tech stack 1. Inertia (What teams are already doing and their comport on language or technology) 2. Industry Standards (What is the popular choice or the time) 3. Hiring (How easy to find the expertise in the market) 4. Anticipate which tech is more suitable for all functional and non-functional requirements 5. How easy is it to build and deploy an application with the chosen stack.
My 3 takeaways are 1. While taking technology and language decisions, consider inertia, existing technology used, industry standard, most supported and feature rich 2. Modules within project should be highly cohesive, have low coupling and based on business domain 3. Application architecture should be done iteratively, architects should focus on supporting team, time to market and one key feature for delivery
My takeaways: 1. How do we take a decision on the tech stack that we want to use? I think the points discussed here very key inertia,go to market time,skillset in team... 2. Don't try to build a perfect architecture... as a developer whenever I write a piece I want that to be fool proof to handle all scenarios, and in architecture I agree its not possible and we need to take decisions as we grow or evolve. 3. modular approach based on features is key I believe.
My notes: - Breaking the complex application into simpler reusable components with distinct boundaries. - Low coupling and high cohesion - Separate the core domain from the rest of application and interact with it through interfaces. - Team skillset, resource availability in market, time to market etc. play vital role in choosing right language and frameworks. Thanks for the useful discussion. Looking forward for similar discussions.
I think boundaries between modules can be defined by knowledge of domain. In some cases, it could be reusability of the particular module in other modules. I think its more specific to the project.
I agree with Koushik on understanding the concept is more important rather terms, because even sometimes I do the same mistake 😉. Few of them are cohesion vs coupling, coarse grained vs fine grained, in hibernate load vs get....etc.
My Learning
To Pick the tech stack
1. Inertia (What teams are already doing and their comport on language or technology)
2. Industry Standards (What is the popular choice or the time)
3. Hiring (How easy to find the expertise in the market)
4. Anticipate which tech is more suitable for all functional and non-functional requirements
5. How easy is it to build and deploy an application with the chosen stack.
Wow this is gold. Thank you Ranga and team
Very useful talk, thank you for the session.
Great session
My 3 takeaways are 1. While taking technology and language decisions, consider inertia, existing technology used, industry standard, most supported and feature rich 2. Modules within project should be highly cohesive, have low coupling and based on business domain 3. Application architecture should be done iteratively, architects should focus on supporting team, time to market and one key feature for delivery
My takeaways:
1. How do we take a decision on the tech stack that we want to use? I think the points discussed here very key inertia,go to market time,skillset in team...
2. Don't try to build a perfect architecture... as a developer whenever I write a piece I want that to be fool proof to handle all scenarios, and in architecture I agree its not possible and we need to take decisions as we grow or evolve.
3. modular approach based on features is key I believe.
Could you do a video on unit testing best practices especially for services which need database to run the code.
My notes:
- Breaking the complex application into simpler reusable components with distinct boundaries.
- Low coupling and high cohesion
- Separate the core domain from the rest of application and interact with it through interfaces.
- Team skillset, resource availability in market, time to market etc. play vital role in choosing right language and frameworks.
Thanks for the useful discussion. Looking forward for similar discussions.
Can we have more details discussion on having the domain logic in service with enamic modes vs domain logic in enetitied and aggregates
What are possible criteria to break system into small chunk and there by promote modularity?
I think boundaries between modules can be defined by knowledge of domain. In some cases, it could be reusability of the particular module in other modules. I think its more specific to the project.
C4 model architecture viewing
ᵖʳᵒᵐᵒˢᵐ
I agree with Koushik on understanding the concept is more important rather terms, because even sometimes I do the same mistake 😉. Few of them are cohesion vs coupling, coarse grained vs fine grained, in hibernate load vs get....etc.