Critical thinking in software development, the word ‘should’, and why you shouldn’t listen to Martin Fowler

Posted on

This might be the case, but a good problem solving process will need to consider other factors than the expertise of the person recommending the approach. For example, for domain driven design you would probably want to ask the following:

  • The techniques are a solution to the problem of creating reliable business rules heavy software. Does your app fall into this category?
  • There will be a learning overhead (all your team must understand the underlying concepts). Do you have time for this?
  • Code overhead: there is much more boilerplate (domain models, factories, repositories etc.) required than in conventional CRUD style apps. Would adding this additional code be worth the extra time?

If the answers to these questions are “no”, then it may well be the case that adopting this approach will cause more problems than it solves. There is no way that citing an authority as an advocate is going to answer these questions for you and therefore doing so should not be weighted as an important factor in the discussion.

Example 2: Let’s use micro-services because Netflix, Uber and Soundcloud do.

>Many household name companies make heavy use of micro-service architectures, a point that any dogmatic micro-services enthusiast will beat you over the head with at any given opportunity. The implication is that because this pattern has been used at multiple large successful organisations like Netflix, it follows that micro-services are all sunshine and rainbows and anyone who has any sense should jump straight on the bandwagon. This is a dangerous non-sequitur.

For Example, Netflix happens to have a product that lends itself to the benefits of micro-services, while being hit by few of the drawbacks. They are a business where throughput and availability are everything. They will know and understand their domain boundaries well, and concerns like eventual consistency and the drawbacks of managing complex deployments are not a problem. They also are likely to see benefits from teams being able to work on services in isolation. Many of these benefits do not apply to most businesses (especially startups). Netflix are the exception, not the rule.

The traditional monolithic architecture, which despite getting a bad name in recent years, has served many businesses well for a long time and does not necessarily mean that you cannot scale effectively. There may be no need to reinvent the wheel.

Prev3 of 6Next

Leave a Reply

Your email address will not be published. Required fields are marked *