Greenfield projects benefit from the DDD exercise to understand their problem domain and where the seams between important parts lie. For existing projects, making the system more modular forces developers to untangle transactional balls of mud and make clearer distinctions between the parts that belong together versus ones that are incidentally coupled.
You will also encounter the team impacts of microservices: how an architectural style drives the restructuring of development teams.
In 1968, Melvin Conway made a prescient observation about software development which has come to be known as Conway's Law:
Organisations which design systems...are constrained to produce designs which are copies of the communication structures of these organisations.
The implications of Conway's Law for software development? Your design reflects your team structure. The common team structure in enterprises is driven by the human resources department, who group like technologists together. While a logical sorting algorithm, it works poorly when designing self-contained services.
In what we have deemed the Inverse Conway Maneuver, many companies now organise cross-functional teams built around domains rather than structured around technology layers. For example, a Customer service might include a business analyst, developers, QA, UX, DBA, and operations person.
Rather than build something passed off to operations for inclusion in the next giant release, the team deploys their service when ready. Many companies using microservices use continuous deployment to get changes into production as quickly as possible.
Business executives might dismiss microservices as the latest buzzword, but those who understand the implications of this architecture can reap real benefits. Microservices can increase delivery speed, enhance flexibility, and gain efficiencies. Their use reorganises work to align on business problem domains rather than technology domains; creates business applications from a collection of independent, more easily developed and maintained, services; better matches the complexity level of the technology solution to the business problem; and builds adaptive architectures that can help restructure existing legacy systems and build new products and services that can quickly respond to changing business conditions.
William Gibson was correct-the future is already here for many companies who view IT competency as a new measure of robustness. Other companies slow to realise this may find their future impacted.
Sign up for CIO Asia eNewsletters.