Microsoft .NET: Architecting Applications for the Enterprise ... - BattleIT

Chapter 1 Architects and Architecture Today 11
words, we were left to choose between either of two unpleasant and painful options: writing
our own Object/Relational mapping tool, or rearchitecting the middle tier to use a different
(and much simpler) object model.
With over 500 presenters in the Model View Presenter–based user interface directly consuming the
object model, having to make this decision was our worst nightmare. We knew it would require a
huge amount of work on the middle tier, consuming both fi nancial resources and time. We lobbied
for more time and successfully stretched the deadline. Then we built our own tailor-made data
access layer for a domain model. (After you’ve read Chapter 6, “The Data Access Layer,” you’ll have
a clear picture of what this all means.)
Changing the Constructor’s Signature
Don’t think that architecture is only about high-level decisions like those involving the design
and implementation of parts of the middle tier. A requested change in the signature of a
class constructor might get you in a fi ne mess, too.
Imagine a scenario where you handle an Order class in your application’s object model.
You don’t see any reason to justify the introduction of a factory for the Order class. It is a
plain class and should be instantiated freely. So you scatter tons of new Order() instructions
throughout your code. You don’t see, though, that Order has some logical dependency on,
say, Customer.
At some point, a request for change hits you—in the next release, an order will be created
only in association with a customer. What can you do?
If you only add a new constructor to the Order class that accepts a Customer object, you
simply don’t meet the requirement, because the old constructor is still there and only new
code will follow the new pattern. If you drop or replace the old constructor, you have tons of
new statements to fi x that are scattered throughout the entire code base.
If only you had defi ned a factory for the Order class, you would have met the new requirement
without the same pain. (By the way, domain-driven design methodology in fact suggests that
you always use a factory for complex objects, such as aggregates.)
Changing a Member’s Modifi ers
When you design a class, you have to decide whether the class is public or internal and
whether it is sealed or further inheritable. And then you decide whether methods are virtual
or nonvirtual. Misusing the virtual and sealed modifi ers might take you along an ugly route.
In general, when you use the sealed and virtual modifi ers you take on a not-so-small
responsibility. In C#, by default each class is unsealed and each method on a class is nonvirtual.
In Java, for example, things go differently for methods, which are all virtual by default.