Not all of a large system will be well designed and this can pull your attention in multiple directions.  The goal is to have the most important part s of the system well designed – strategic design.

Take two loosely coupled systems that have grown independently, but are starting to move toward interaction.  The decision was to move towards a new system, by

A series of steps –  But, it’s never going to work like that. Why?  as the old business logic is taken there will be more and more parts of the old system that take inadvertent amounts of time.  This will lead to just porting sections of code, without re-design and this cannot be well tested.  Which, means your new system ends up partitioned into old and new sections – coupled with changes to the original system can mean the project will just end. What are the alternatives:

Refactoring – keep the system running and change parts by increments.  You have the danger here that the best people work on the new items and the others work on system updates, but do everything they can to work on the potentially good stuff.

Note – the real mess is made by the 2nd worst dev on the team , as everyone is watching the worst like a hawk.

Lets Hack – this will just end up in an almighty mess

But, whichever of these 3 approaches is taken you are prone to end up with the Lets Hack endpoint.  So is there a potential solution? How about Domain Design and the core principle  ‘Distilling the core domain’.

Break it down into 4 categories (which are not trivial to figure out)

• Generic subdomains – often possible to get these off-the-shelf or outsource it
• Supporting subdomains – possible outsource
• Core domain – direct trace-back to the fundamental goals, also often the smallest part of the system, but, is what makes the system worth writing.  This is where you should put your key efforts, as it is the key to success

Often the core domain is  often left to last, as all the infrastructure and rework is done first and sometimes this is never completed. Therefore, the fundamental goals are never achieved.

There are always multiple domains so they are inherently always wrong The blind men and the elephant by John Goderey Saxe example of how multiple domain models can come about.  Your aim is to find a model that is takes into account the core domain and is consistent within the context of its boundary.  Within this boundary you should be able to achieve a ubiquitous language that is usable by all team members. You should also have no duplication within the boundary which defines a unified context.

So to skip to the core domain rather than build all the supporting layers first you could form an Anti-corruption layer – isolate from the other parts forming a platform on which you can start to build the core domain.  The anti-corruption layer will not be pretty, but it gets you to a point where you can move forward with the fundamental goals far sooner than the alternative route, that often never gets to the core domain, let alone completing the legacy migration.

you should aim for:

• Stability
• Reasonable Operating cost
• Suitability to task
• Adaptability

Remember to:

• Clarify context map (map what is there)
• deliver early and produce enthusiastic business sponsors – to gain influence
• focus on core domain
• create a platform

and as a responsible designer you should:

• clean up other peoples mess
• Build a platform to make other (lesser) programmers to be more productive
• allow the lesser developers to work on  the sexy new functionality, while the stars work in the core domain
• make the lesser programmers look even better – remember they are often working in the core domain while the great programmers are working on sexy stuff that does not directly influence the fundamental business goals.