When is domain-driven design adequate?

Most books about DDD talk about aligning the tech to the business. So you have orders and payment business rules and such.

What if I write a technological applicaiton. For 开发者_如何学Goexample if I author a visual studio like app. Is DDD not relevant, or can I say that my domain is "application development" and identify the players ("solution", "file") and business rules so I can apply DDD.

What you have here is simply a case of where the business domain is technical; that's no reason to not use DDD.

In some ways this makes it easier - because you're automatcially a Suibject Matter Expert (SME) in "the business" domain in question.

In other ways it'll be harder - you may find that terminology "collides".

For example, if you're modelling the system you may have technical terms modelled as though they were business ones. We've all seen class diagrams with entities called "Customer" and so on; but having an entitiy called "Class" would quickly lead to problems - especially if you want to use that to generate code.

The domain of your technological application should be aligned to the language how the users of the system will talk about it. So with a development tool you may have projects, files, properties etc

Domain Driven Design is almost always adequate. Go for it. :) Also it may be a good idea to look at some IDE implementations like http://www.sharpdevelop.net

DDD is suitable for large appications. I guess your IDE will be large enough. Probably you will not need repository patterns but rest(value objects, entities, services) will be presented.

When we develop something, there's always a purpose in that, a target. That target is your domain.

In this case, you are going to develop an IDE. You need to think about how to solve the problem of "developing applications". That's your domain.

You doubts come from the fact that "software development" is not used as an example in DDD.