Easy design decisions

Of course you know why and how to prevent "meat-ball" designs characterized by no adequate modularity (spaghetti) and no functional separation (e.g. multiple message types combined to one). You don't need an architecture or any standards for that. As a professional designer you just know; it's you craftsmanship.

But are you designing an IT-system and do you have to cope with equally valid alternatives that are not addressed in the overall architecture? And there are no standards defined? Or there is no architecture at all because of the low maturity of your IT-organization? Then these criteria may be of any help to you:

Maximum flexibility (future changes)

Choose the alternative that needs the least effort when requirements change. E.g. if you must decide whether to implement JMS-topics or to implement JMS-queues, prefer topics over queues. Queues can only deliver to one consumer whereas topics can deliver to mutiple consumers. So if - in this example - a second unforeseen consumer pops up, no changes are needed to the system.

Robustness (self healing)

Choose the alternative that doesn't break the system when failures occur. E.g. if you must decide whether to implement durable subscription or non-durable subscription, prefer durable over non-durable. In this example there will be no loss if a consumer goes down for a while; the system recovers automatically when the consumer is up again.

Open standards (lower costs)

Choose the alternative that is based on open standards. E.g. if you must decide whether to use a JMS-API or an MQ-API, prefer JMS over (proprietary) MQ. This makes you less dependent from specific products and suppliers, which improves flexibility and lowers costs. In this example you don't need to change your programs if they must run on another messaging infrastructure.


Of course these design decisions must be challenged against aspects like performance and scalability. E.g. durable subscription may lead to huge databases for the required persistency. But let these aspects be an afterthought and not be leading for the design. First create a design based on the criteria mentioned above and then - afterwards - start tuning the design based on pragmatic aspects; and document why and how you tuned the design. As to-day's limitations need (will) not necessarily last forever, you will be happy to be able to easily upgrade the design when the limitations no longer exist.