For this question, let's assume the following:

  • OOP design principles are being followed.
  • Modules generally do not consume more than one general concern, but different business purposes.
  • Hybrid application (multiple platforms).
  • Covers single business concern. However, this single business concern has several smaller concerns that could technically be their own applications.

This application should be used as the example "model" for the following question... is there any advantage or disadvantage to following a microservices architecture versus a standard "one giant application"? Does this inhibit the ability to efficiently share and exchange data between the different parts?

  • 2
    I think this is a business decision that depends almost exclusively on your marketing strategy and on your customer base. This isn't really a software engineering problem and from a technical standpoint there's no strong preference either way. So we can't tell you what to do. Once you've decided, you're welcome to come back here with concrete questions regarding architecture or design of your system.
    – amon
    Commented May 28, 2017 at 17:26
  • 3
    I would recommend against allowing your sales and marketing narrative to decide your architecture. You may decide to offer a single product to your customers, but that shouldn't deter you from separating your different business concerns and splitting that product into a loosely-coupled set of modules and back-end services. Similarly, your marketing narrative might decide to offer a range of products, but that shouldn't deter you from creating reusable code libraries and storing everything in a single database, or allowing multiple applications to reuse the same service(s). Commented May 28, 2017 at 17:30
  • 2
    @BenCottrell: it is not architecture. The question is about products, that is the way a system is presented to the end user. How the system is really done and how a user perceives it is not the same thing. Otherwise, nobody would dare use Amazon or Netflix. Commented May 28, 2017 at 18:11
  • You changed the question into a completely different one. Commented Nov 8, 2017 at 9:43

2 Answers 2


Arseni Mourzenko's answer is not bad, but I guess he did not cover your question in full. I agree to his point that feature control from the end users point of view is mostly independent from the internal component structure of a software product. Feature control is IMHO the wrong decision criterion for "using one large component" versus "using many small ones".

However, the internal component structure matters heavily from a software engineer's point of view. The major consensus today is that developing many small, independent components which are mostly decoupled from each other, each one with just one responsibility, is much easier than to develop one huge, complex component with many responsibilities. This is surely a trade-off, lots of small components require, as you already mentioned, additional interfaces and a way to exchange data (like user data or session information) between them. However, on the pro side there is

  • much better parallel development (each component can be developed by a different team or person in parallel)
  • much better testability, maintainability and evolvability (each of the individual components can be tested on its own, which makes it easier to write automated tests, to identify the root cause of bugs, and to manage changes)

Of course, there is no "silver bullet" or consensus how "small" components should be. The depends heavily on the overall size of the system and the team's size - the bigger they are, the more important it becomes to split up the architecture of a system into smaller components.

For example, in the world of web services, this discussion lead to the idea of Microservices. For small products and solo developers, however, such an architecture may be too finegrained and could add far too much additional overhead.

We don't know how big your system and your team is, so only you can make a decision if you need many small components or not (but, as I said initially, not based on the fact you need to provide feature control).

  • +1 In addition, the OP states, "I would think that it's easier to just build and maintain a single "conglomerate" product with the ability to enable or disable certain features" - there is much complexity and room for error in turning features on and off ("Oops, we forgot to enable the 'Done' button when turning on feature XYZ").
    – dj18
    Commented May 29, 2017 at 15:17
  • And more than just parallel development, but responsible development: When each team takes ownership of their own module, they know the business logic, they know the code, they take pride in their code. When everyone works on everything, then no one owns or cares about anything. (Speaking from experience here.)
    – dj18
    Commented May 29, 2017 at 15:24
  • @Austin: google for "best practices microservices" and you find lots of answers. However, don't expect a clear consensus.
    – Doc Brown
    Commented May 29, 2017 at 18:30
  • @Austin: do you expect me to jump into my Delorian and travel 100 years into the future to collect this information from some books about "ancient history of IT systems"?
    – Doc Brown
    Commented May 29, 2017 at 18:45

Technically, it doesn't matter.

Look at Netflix. How many products do you see? Only one. And yet, Netflix is a conglomerate of dozens of services which can be developed and deployed independently, using an independent technology stack.

Now look at a random SquareSpace website. And then pick another one. They may have nothing in common. Two different products, using two different sets of features. And still, the underlying programming code is the same for both.

So if the question is not technical, what is it, and, more importantly, who decides?

The actual point is how do you present your product to a customer. It may make sense to present a series of features as a single product. Or it may be more useful to present the system as multiple products.

Take Microsoft Office. Shared code (except Excel), multiple products. You have PowerPoint, and you have Word, not because it would be technically impossible to combine both features of a text editor and a presentation editor into one software product, but rather because users wouldn't understand how to use such product (according to Microsoft).

Now consider Visual Studio. If I write C# code for server applications, and that's all I do, I don't really care about Visual Basic or F# or C++. And I don't even care about Silverlight or WPF or Windows Forms. Nevertheless, it's all in Visual Studio, in a form of features. All in one place. An interesting point is that it wasn't always like this. In the nineties, you had to install different IDEs for different languages: if you used two languages, you ended up with both Microsoft Visual Basic and Microsoft Visual C++ applications on your machine.

Therefore, the decision belongs exclusively to marketing. Once the decision is made, it's up to you to develop the software product in a way that ensures enough cohesion between the parts of the system and avoids code duplication.

  • I downvoted because the question specifically asked "from a programming standpoint", and you framed the question as "who defines the implementation". You're right that the user experience should be defined first and that after that, the technical implementation should be planned and decided on by the developer team to meet that user experience. And today, the gold standard in software architecture for SaaS web apps seems to be decoupled microservices, not monolithic systems with a single Enterprise Model. Anyway, a marketing team doesn't usually define user experiences. A UX team does. Commented May 28, 2017 at 23:05
  • 2
    @RibaldEddie: and I answered: from programming a standpoint, it doesn't matter. In my opinion, it's not even about UX—the choice is of a larger scope than any UX choices. It is, however, based on that choice that the UX team will build the actual experience. For instance, the choice to make Microsoft Excel behave very differently from other Office products is a high-level marketing choice (the independence of Excel's team vs. user's relative convenience of a common interface). Would it be the choice of UX team, Excel would behave exactly like other Office products. Commented May 29, 2017 at 3:06
  • I don't believe that MSFT doesn't treat product development and marketing as two separate things. And from a programming standpoint of course it matters. In the case of MSFT do you know the history of that company and its products? I know for a fact that they spent years working towards a decoupled codebase. Commented May 29, 2017 at 3:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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