A Developer is NOT a Domain Expert

My issue at hand is when developers are tasked to design the business solution (not technical solution) because they believe or their superiors believe that they have the skill-set to design a business solution to solve real business problems.  Stop it! A Developer is NOT a Domain Expert!

To clarify, most developers are not domain experts (other than the  domain of development).  The developers that do have a skill-set that allows them better define workflow and use cases are usually described as “rockstars” or they end up in working for themselves consulting.

Domain Driven Design

Domain Driven Design

First let me provide background to give some context.  I live in a professional development services, dealing with business customers in a variety of domains/industries, creating business applications.  We are often approached to create a custom software solution to solve business problems or to fill a gap.  In most cases, the business solution has not yet been designed, or has been design but is arguably not the correct solution.

In my experience, most developers are not business analysts and do not have the proper experience or knowledge of business (models) or skill set to create a business solution that truly solves business problems.  Yes, we can create exactly what a user requests.  Yes, we can provide suggestions for technical or usability features.   Yes, we can create a great technical solution.  However, we need to understand our capabilities and make the customer understand we don’t own the content or are the subject matter experts. Too often developers are put into situations by themselves, leaders, or customers that they do not qualify nor should the have the responsibility for.  Just because you can create any piece of software, doesn’t mean you should define the business solution.

I’m a strong believer in Domain Driven Design.  Collaboration between domain experts and developers is essential when creating software for a complex domain.  However, don’t be fooled thinking a developer understands a foreign domain enough or better than a domain expert in order to fill that role.

Note: This article was rewritten to differentiate between Developers and Domain Experts instead of Developers and Business Analyst.


  1. Kenneth says:

    This post is wrong on so many levels in my opinion.

    I think what you are describing is not a developer but a coder. Now, there may be a lot of confusion in terminology (coder, programmer, developer, …) but I think in modern software development a pure coder is of very little use. You need your developers to be on the same level as your domain experts (at least for that part of the domain that they are trying to solve).

    I think it’s wrong to assume that you need to separate this. That’s the whole idea on which DDD is based: let the domain shine through in your code so your developers and domain experts speak the same language. Adding a business analyst who presumably doesn’t code just adds another layer of indirection. In my experience, the most frictionless way of developing is by having a direct communication between devs and domain experts. It also helps with developer involvement (although that’s a completely separate issue).

    Your analogy is also wrong in that Henry Ford would be the domain expert, not the business analyst as you’re implying

    Also, a business analyst wouldn’t “build” something, he would analyze the problem at hand and translate it into a spec.

    Disclaimer: I am not trying to discredit you in any way, I’m just of a different opinion and hope you do not take this as a personal attack.

    • I agree with you about DDD and having your developers interacting directly with domain experts. My point is not to suggest that developers be “dumb” about the domain. My point is, unless if you have lived in a domain a very long time or understand the business model, you have no way of knowing what the actual root cause problems are or if the workflow that an organization is using is actually the best way. A business analyst will.

      A prime example of this is the context of solution manufacturing, such as Mold Making (automotive). I live in a product in this doamin. Almost all solution manufacturing companies use software and ERP’s designed for product manufacturing. Those are two different business models. If you were to sit down with domain experts and follow DDD, you would come out with a solution that resembles their current workflow. The problem is, their current workflow is fundamentally what their problem is. You would be automating and making efficiency improvements on existing workflow rather than actually solving their real problem. Their real problem is lack of data and relation. They couldn’t tell you that. They usually point to inefficiencies. They do so because they can’t imagine and realize what the real problem is because they have been so ingrained into their existing systems/ERP’s that do not fit their business model.

      In this example, a developer practicing DDD with domain experts is not creating a better solution. They are going to create exactly what the domain expert does already.

Leave a Reply

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

eight − = 5