Our current business process is that the domain experts will write down the business logic in a Word document, and developers will try to reflect those logic as closely as possible with the implementation.
This process violates the DRY (do not repeat yourself) principle, and thus creates many problems that are associated with violating DRY principle.
There is no programmatical way of determining if the change in the domain document is correctly reflected in the code base. This forces very close-knit communication between the domain expert and the developer, which causes other problems such as the document resembling more of the tech specifications rather than the domain specifications and frequent meetings if any part of the document needs to be updated.
Note that I am a developer, and I am not looking to introduce a solution that requires an adoption of a software approach by anyone but me. I am trying to find a simple solution that can be handled by a single developer.
I've done my research and have encountered some suggested solutions such as domain specific language or domain driven design, but they don't fit my needs for the following reasons:
- DSL: This requires the adoption on the DE's part to use the DSL. I can use DSL to implement the domain logic using DSL, but this doesn't resolve the underlying problem of separation between domain document and implementation. Also, I do not want to limit domain expert's ability to express domain problem to specifically DSL. I want them to be able to use natural English.
- DDD: A bit better than DSL in that only the ubiquitous language needs to be developed, but this still requires explaning the concept of DDD to everyone involved.
In essence, I am looking for a simple solution that can be contained by a single developer. One ideal solution I was thinking was have some tool that can somehow annotate a section of the documentation to the specific code implementation, so that at least we have a brief visual cue of how well covered our documentation is.