Why do we tie domain objects and service interfaces to specific applications, sometimes all in the same assemblies and namespaces?
How can application interoperability survive the evolution of the business' domain knowledge/model? When applications finally get rewritten, they're typically also renamed, and frequently application borders are redrawn. This happens largely due to evolution of business domain knowledge. How can application interoperability survive? One answer: The new app can implement the old app's interfaces w/ proxies - in their own namespaces and assemblies - that consume the new app's interfaces. While the temptation in a DI-enabled environment might be to just have the new app directly implement the old interfaces, that presents a growing burden on successive iterations of software. Better to have independent proxies that can cascade, and that can be dropped as needed.
Think about what best practices would incorporate all of the following in enterprise-level apps:
- Dependency Injection
- Interfaces
- Domain objects
- Namespace boundaries
- Application boundaries
- Assembly boundaries and version numbers
- What should be in the GAC, and what should not
No comments:
Post a Comment