Well known is the split of a whole application into several bounded contexts to emerge an Ubiquitous language. while practicing Domain-Driven Design.In general, 1 bounded context = 1 archive file ready to be deployed (JAR / EAR / DLL etc..) My question concerns the bounded contexts deployment regarding hardware optimization:Suppose I want to optimize one specific service within a specific bounded context (optimization could be a more powerful CPU, more RAM, etc..), is it a good practice to create a specific archive file just for it? Meaning to split further the initial bounded context.Thus, in order to deliver it on a specific hardware tunes for its usage.                Or should I consider 1 bounded context as being an indivisible unit and therefore optimizing the bounded context as a whole even if some specific services doesn't need this increase of hardware power?
DDD / Optimizing a specific service belonging to a specific bounded context regarding hardware
architecture;domain driven design;enterprise architecture;hardware
I consider software implementation (i.e. the writing of the code) to be a somewhat different thing than the conceptual design.  The conceptual design is there to see how all of the software components work together.  But a good conceptual design will always allow the underlying implementation to be altered to meet the software's performance and reliability requirements, and you don't necessarily have to reflect those implementation details in the top-level design.When you design a car, you know that it's going to have a chassis, wheels and an engine.  That's part of the top-level design.  The wheels are going to be round, and they're probably going to be made of vulcanized rubber.  But the speed and mileage ratings of the tires are implementation details, and so are the engine specifications.In short, the overall design should not change based on a hardware change or an infrastructure change.  Good top-level designs are independent of such details.