Domain-driven design
What are the reasons for NOT using it (building business software)?
According to Wikipedia, "Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts". We at Attracs have been working like this since long before we knew it was called DDD. I started thinking about why you wouldn't want to work like this when building business software.
Sure, there can be problems making DDD more difficult, for example that the abstraction level of the tools used are too low, making it hard to grasp the core model. It could also be that the customer tends to turn focus away from the core domain, and into various other functional and nonfunctional requirements. Yet another problem could be that the people designing the system don't really understand the core domain of the system they are trying to build. But tools can be improved, customers be made aware about what they really need, and develpoers can learn the core domain of the system. Therefore, in my opinion, the only really valid argument agains doing DDD, is that the core domain itself isn't really worth building a system around.
This is not the case with Attracs Online, as we stronlgly believe both in the core domain of the system (Online Planning) and the people and tools used build a system around it.
Add new comment