How to convince my boss that we suffer from a seriously anemic domain model.

I have been working at my current firm for the last year and a half and I have been recently promoted to manager. My input, as of late, has been weighed into architectural considerations far more than ever before. Well, I am one who loves software development with a passion and will do anything I can to become a better developer. Recently, I have been studying concepts such as Dependency Injection with IoC, Domain Models, Three-Layer architecture, etc (Several principles from Patterns of Enterprise Application Architecture, which I have begun re-reading).

We are in the beginning stages of a new full-scale ERP system and one of said beginning stages was to build a smaller application that would essentially lay the framework for our new ERP. We would test out design patterns and new ideas in this smaller application. Lately we have been discussing some serious design changes to account for unit testing–something we do not do. We have had customers ask about unit testing and we unfortunately do not have anything for them. My boss and the lead architect are both against unit testing in many ways (Granted, they have not ruled it out completely). This has been an issue I have discussed with them many times, as I am very in favor of unit testing. The major issue is our design style. Anyone who has read PoEAA is familiar with the Transaction Script pattern. This is what we do. It is what we have always done. It is now failing us.

Our older applications that were written in C# are now notoriously difficult to maintain (I am the one who maintains them most often) and the issues are becoming more and more apparent. In due time, we will reach the tipping point on our new applications and they will be impossible to maintain as well. This is a huge problem because our newest application that is largely in the design phase will rely heavily on easy maintenance and extensibility, something that is nearly impossible considering how we currently program. What is worse is that the lead architect has created these auto-generated objects that are Active Records to the 'T'. They combine business, data access, and UI Binding logic in one bulky and obtrusive object. I have made arguments to separate this object into several different components to make them more flexible, but the response I almost always get is, "Don't use them that way," or "These objects have one specific purpose and thus we don't need to separate the components." Both solid points, but the problem is these objects are a direct representation of our SQL database in code. Think entities in EF, just super heavy weight.

My challenge is to show my boss and the lead architect that we need to change things, and fast. I love the Domain Model as explained by Martin Fowler. Whenever I speak to my boss (who, realistically, doesn't work on these projects so he defers the decisions to the lead architect) or the architect on formatting the logic in a way that separates logic operations into more classes that have a specific purpose, I hear the excise "We will have too many classes and interfaces to maintain, making our application impossible to maintain in the long run." I disagree completely. Frankly, large, 800 line transaction script methods are harder to maintain and much, much more confusing. The other issue is that the lead architect created almost everything we have in our new applications and I do not want him to think that I think he is stupid or a bad developer. He isn't. Quite the opposite. I just think he possibly overlooked some things when designing these new applications. Either that, or he is just used to doing things the same way he always has…

So, after that long introduction, my question for all of you is this: What would you do to promote a fresh Domain Model that can easily integrate with Unit Testing and possibly a DI-IoC framework? I assume that the standard practice is to follow the ideas described by Martin Fowler in PoEAA. If this is not the case, resources describing other Enterprise level design patterns and considerations would be appreciated.

Lastly, I am not saying that I want to completely replace anything that has currently been designed, rather just refactor our current code or any new code to follow a more OO-like design. Transaction Scripts have their place, just not always in Enterprise Applications, and certainly not as the only methods of execution.

TL;DR We have an Anemic Domain Model and I need to convince the powers that be at my firm that a change is needed for our newer applications to be optimally successful

by BlackFlash via /r/csharp

Leave a Reply