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?


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.

| improve this answer | |
  • Thanks for this explanation. I would take an example: I have a Meeting Context (bounded context), containing a ParticipationService, VoteService (to elect the best meetings) and a MeetingCrudService (create meeting delete it etc..). I consider all these services as being part of the same bounded context. However, surely VoteService is used more often than a participation to a service etc... explaining the need of a different hardware for optimization. Does it make sense to split this bounded context among multiple distinct archives files in order to deploy them independently? – Mik378 Apr 22 '14 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.