Domain Object and Contracts

As a team we have found ourselves in a very delicate situation where we had to make a group design decision and it was quiet an interesting experience. What happens if your opinion does not align with the decision? How do you express your opinion without suppressing others opinions, promoting your concepts without falling into the nasty habit of ignoring anything that is different?

You discus. Can't prove that what your idea is all about is the way to go, that means it's either not better or you haven't really tried to explain it to others so they would see the benefit and be convinced. Conclusion - take your time, step back, see what's going to happen, accept what the team has decided, and if you really thing that's not the way to march, start thinking of a better way to debate your case and have some solid proof of concept.

What's the noise about? Domain objects and contracts (aka interfaces) for those. As a team we have decided today to have contracts for all of our domain objects. Valid decision, that will keep consistency in our code, and tests (where the debate started). But why this was an issue, after all, isn't it a fact that contracts are good and promote healthy way of coding?

The answer is Absolutely. Yet why to have an artificial contract on something that is a contract on its own? Domain objects are contracts for the whole application from bones to skin. If any of these objects (contracts) is changing, it's not like swapping out a component that was coded to a contract, it's pretty much reviewing the whole application and touching the code. Naturally a doubt sneaks into your soul and the question bubbles up - then why do I have to have a contract for a contract?

As a team we run into mocking issue. Mocking would have required a solid object to have either a contract or methods/attributes defined as virtual to allow mocks proper creations (proxies), but due to the fact those were missing the virtual keyword, tests were really misbehaving. Using a simple Root Cause Analysis we've determined that it's the fault of the 'coding process' that allowed this whole issue to happen, and that having contracts in place would not let developers go the path of cracking what's wrong.

As a team we decided that despite the fact domain objects are de-facto the contracts, we still will use contracts to simplify the process of software development, and have conventions over configurations.

1 Comment

  • Interesting problem...ran into the same one at work just recently. The issue we were debating was basically should we completely re-architect our coding practices and go with the interface-for-everything idea _just_ to support one style of testing, or let the developers write the best code to support the _application_ + users, and then test it in whatever manner we can??

    A few argued that the TDD style of "unit" testing was just one way to test, and not the only. The rest of the argument was oriented around "if I have a Car object, and there is only ever one type of Car object based on the design spec, why in the world would I waste the time abstracting out an interface?". Also in the mix was "the compiler will tell me if I/we broke a signature, and then we'll go fix it and move on - it's really not hard".

    Thoughts?? I was at a loss to combat either side of the argument...one side resonated with my OO side, the other lit up my pragmatic side.

    Cheers!!!

Comments have been disabled for this content.