If the other project is the same kind of business, the volatilities might be similar, so the components might be similar. But, no project is ever completely the same so nothing can be reused 100%.

I heard Juval say somewhere that components don't get reused, only interfaces do.

probably its 9 years old!!

@@wennwenn1422 9 years ago we already had Full HD video and all the microphones required

I don't think so.

I don't think their focus is the same and here's my reasoning. Volatility based decomposition focuses on the volatility that exists in the problem space and explicitly encapsulate them in components. The system model will probably not resemble the business organizational model because the business capabilities appear only as a result of the interaction of the different components. Doman Driven Design focuses on mapping business domains to component(s) so that a component or a set of components will encapsulate a particular business domain/capability and then further more business objects and concepts. The system model is almost a good representation of the business organization model (we normally say in DDD that teams map to business capabilities and are responsible for one service or a set of service related to a domain). Moreover, the simple fact that DDD does not explicitly consider volatility means that there are good chances that it will be spread across services and across domains.

Fabric is an abstraction; it is a portion of the network. Normally, it is within the same control plane and uses technologies such as VXLAN or VLAN. Every fabric offers a set of unified services as well as primitive constructs to create and manage a logical network based on user requirements.

Well perhaps not the timeline, but Service Fabric Reliable Actors can be considered an implementation of "every class as a service"

a little too 'little'? i don't know how to interpret this but my gut feeling is that you don't respect the point i've made. i am most certain that we are not in agreement. you are telling me what the architect does. i am telling that i have seen actual horror stories where there either was no Architect or there was an Architect but the architecture was undermined by developers who may have had the best intentions. and i am also telling you that i have seen actual situations where the Team Lead was making poor choices. in particular, several Scrum environments have wrestled with poor code-bases. it is in these environments that i have seen the Role of the Architect under attack. finally, i wish to take issue with the claim that a concrete implementation for a particular detail won't change the architecture. if that developer were to introduce dependencies that should not be present, then i don't believe that this claim would be true. draw the architecture in layers and the arrows should go down. this is a heuristic that actually helps to control the orgy of interactions that would otherwise occur. but i have seen arrows that travel all over the place. and the Architect may have been unable to intercept this code prior to submission. then again, there may not have even been an Architect. but the damage was done. so, i apologize for stepping on your toes. were you not trying to tell me that there was something i had not properly understood?

Mohd Nazmi, no. I thought about it. No peace. I don't say "peace" while simultaneously questioning someone's sensitivity and lecturing that person. No mixed messages. I am replying because I choose to. I told you what I had seen because I am asserting that this is the way it is in many shops. I corrected you because I don't believe that you know what you're talking about.

YAGNI is against speculative development, not volatility. Also volatility does not promote over-engineering, which is what YAGNI is against, so what are you talking exactly about ? Hopefully, you learned more about YAGNI by now :)