Life without Stupid Objects, Episode 1

So, this is not, strictly speaking, the next post to the previous post. Along the road, I realized I was using a certain style in the little code I wanted to show, and that it wasn't the style most people use, and that it would be distracting to explain that style while trying to communicate a much more important concept. 

So this post is about persistence and a way of writing repositories. Or it is about avoiding objects with no methods and mappers between stupid objects. Or it is about layered architectures and what constitutes a good layer, and why we shouldn't pretend we have a layered architecture when we don't. Or it is about applied physics of software, understanding our material (software) and what we can really do with it. Or why we should avoid guru-driven programming. You choose; either way, I hope you'll find it interesting.


"Line of Business" applications
Consider the usual business application: you insert, search, edit, and delete a variety of business entities, usually storing those entities in some kind of database. There is some logic kicking in at specific times, from simple validation logic to complex calculations and workflow actions. Sometimes, data is transformed; very commonly, it is summarized in reports. In many cases, it is persisted in a form which is not really different from what you see on the screen. Needless to say, there is also a user interface to do all that, and today, it's very common to go for a web application.

Let me leave the user interface aside; it's a large topic, and would (will) deserve some separate discussion. What is a reasonable shape (architecture) for all the rest? This is not a new question, and you can find many answers, picking from the various patterns in Fowler's et al. (Patterns of Enterprise Application Architecture), from the architectural suggestions in Evan's DDD book, from to the reference architectures coming with specific technologies (like the now old EJBs) or toolsets (e.g. O/R mappers), etc.

The sheer volume of knowledge is so big that we face a problem of depth vs. breadth. Either we cover a lot of alternatives, but at a rather superficial level (like in Fowler's book) or we choose a particular style, and we go down deep, possibly providing an implementation as well.

At this time, I'm more interested in discussing forces and how they are shaping different solutions. I'll be focusing on a rather popular style, not because it's necessarily the best, but because it's a good example of how stupid object may arise out of good intentions, and how can we cure that. In this sense, this post is more like an example of "applied physics of software" than an attempt to discuss every nuts and bolts of every possible choice. In the end we'll see some code as well, because some properties are better appreciated through a few lines of code than through endless babbling.

Forces, layers and decisions
Of course, most of you guys already "know" how to do this. Sure, you may all have different architectural preferences, but there is a strong tendency to go for this overall structure:
- a database of some kind (often SQL, sometimes NoSQL)
- a "persistence layer"
- a "business layer"
- (possibly) an "application layer"
- (possibly) a "service layer"
- (a "gui layer", which I'll ignore)

Where do those layers come from? What is a layer, exactly, anyhow? It isn't just a random grouping of classes / functions / modules, right? What is the purpose, definition, and role of a layer in a software system? You could head for "Pattern Oriented Software Architecture, Vol. 1: A System of Patterns" (Buschmann et al), chapter 2, go to the Layer pattern, and you won't find an exact definition of a layer :-), but you'll find its responsibilities: "Provides services used by Layer J+1. Delegates subtasks to Layer J-1". Hmmm. Well, ok.

Layers, by nature, are a grouping mechanism, wereby we grow software by stacking abstractions "vertically", while grouping similar software abstractions "horizontally". Why do we give that shape to our software? In the physical world, a shape is the result of applying a force (this is an interesting insight from D'Arby, to which I'll return at some point), like compression of shear. In the software world, the shape is always the result of applying a decision.

Many decisions are taken without even thinking: for instance, we decide that data must persist between sessions, even if we turn power off. That's sort of a given and people don't even realize they're choosing something.

Some decisions are technological in nature:  we decide that we want to use a SQL database. We decide that we will use Oracle. We decide that we won't use stored procedures. Etc.

Some decisions are business related: we decide that we want to support multiple authentication techniques. We decide that we will greet the user with a "happy birthday" message if he logs in at the right time, etc.

Decisions are unstable. Some more than others (this will largely be the subject of my next post). Now, in a 40-year old paper you can't afford not to read (On the Criteria To Be Used in Decomposing Systems into Modules, and yes, that's forty years kids) David Parnas said: "We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others"

So what is a good definition of a layer? A layer is a group of abstractions, hiding one or more internal decisions plus all the decisions made inside the underlying layers. Therefore, a layered system is "good" when you can actually change a decision made in one layer, and none of the layers stacked on top of it needs to change. In order for that to happen, a layer should avoid replicating/exposing the responsibilities of the underlying layer.

Let me give a proper example. In the quintessential layered architecture (hardware abstraction in OS) at some point there is a portion of code dealing with virtual memory, and how you manipulate CPU-specific things to make that happen. This is not exposed to the upper layer (it could be, but it's more like a backdoor). Instead, we get a new abstraction (virtual memory). Languages like C# and Java effectively add another layer, basically hiding the concept of addressing at all (still exposed in C and C++). This in a sense is the best layering, as the concept disappears and we don't even speak of a "memory layer".

Contrast this with a business layer built on top of a persistence layer, and yet exposing/replicating the persistence responsibilities (say, CRUD) for the application layer to call. This is not an ideal layered architecture (sorry), because your layers are becoming bigger as you travel up, and changes made in a lower layer may end up being reflected in an upper layer.

In practice, it's quite rare to find a problem (forcefield) which lends itself well to true layering. In many cases, layers are brittle, that is, most of the decisions made inside those layers can't actually be changed without breaking all the layers above. For instance, if you aim for the Buschmann book again, you'll find an example of layered design for a chess game, explained as follows (from bottom to the top):

- Elementary units of the game, such as a bishop
- Basic moves, such as castling
- Medium-term tactics, such as the Sicilian defense
- Overall game strategies

In practice, you have very little latitude for change in every layer: you can safely change only minor implementation details. Suppose that you change a "major" decision ("business rule"), like the basic moves of the games. You allow some previously illegal move, or vice versa. That requires a change in layer 2. However, that change would immediately invalidate all the upper layers: layering is not so effective here.

It is also worth observing that layers, although conceptually simple, are extremely constraining, as they basically define a single dimension upon which you can stack your abstractions, and therefore will push you toward a design where you have to identify a "principal decomposition" (contrast this with the goal of aspect orientation to free you from the tyranny of the principal decomposition).

In most cases, developers choose technology as the principal decomposition in Line of Business systems. I want to stress the fact that it is a choice (a decision), and it is not inherent in the concept of layers or in any design paradigm, but it's still the most popular choice.

Why technology?
Once you see a layer as a set of artifacts that are somehow "squeezed together" by some force, you can easily see that technology is only one of the forces acting on your artifacts.

Sure, you have a force saying "let's squeeze together all these classes, as they know they're dealing with SQL", the rationale being that if you change to NoSQL, you want to "change only one layer" (sooner or later, I'll come back to the concept of entanglement and explain this stuff better).

Yet, you have at least another (orthogonal) force, pushing all the technologies together, and layering the system according to the domain instead, the rationale being that if you add a field to one of your abstractions (like a title, so you can say "hello Dr. Something, happy birthday"), you only have to change one abstraction. When you choose technology as your principal decomposition, this decision is spread among layers instead, giving place to an unfavorable entanglement field among many "distant" abstractions (I consider layers to be somehow distant in the artifact space).

There is also another force. I'm sure many of you felt it, but frequently decided to look the other way :-). It’s a force pushing the logic toward the data, which gave rise over time to things like stored procedures, still considered like dirty, non-portable hacks by many. And yet, as you move toward a distributed, NoSQL solution heavily based on map-reduce, you'll see your (distributed) data attracting more logic, with nodes offering higher-level services, effectively subverting some of your layers. But we can't talk about these things in public.

So, in the end, people ignore all that and favor technology as the principal decomposition. There are many valid, and many non-valid reasons to do so. I won't even try to enumerate, as reason #1 is "all the gurus are telling us this is the right decomposition" and you can't argue with that. Still, trying to list your reasons and ponder on the validity of each one is an interesting venture in self-awareness :-). For instance, division of labor and technical specialization seems like a good reason, but is not without consequences.

Note that, in the typical line-of-business application, the distinction between the "application layer" (or "use case layer" as some call it) is not necessarily driven by technology. Actually, that line is blurry, and again, it's mostly being accepted as reasonable because the gurus tell us so, not because it is technically bulletproof. The typical definition is that the domain is about things that "are always valid", independently of the application / use cases, while the application layer realizes the use cases by delegating to the domain layer.
Makes sense, except when you look again, and discover that "always valid" makes no sense whatsoever. For instance, my User class is offering a date of birth field (and possibly an IsBirthday() method) because my application wants to greet the user. Were I just interested (e.g.) in geolocating my user, that function wouldn't be provided, that field wouldn't even be there. So much for being part of the domain, then.
In the end, many people bring in technology again as a criteria to separate the application layer and the domain layer, by stating that domain objects should not know about persistence (which de facto alters the stack, but they don't say so because the gurus never said so). This brings us to the next big question.

Acceptable relationships between layers
Some relationships are basically imposed by the function (which here determines the form). Some are free for us to choose. Of course, choosing some relationship is akin to choosing a stacking order, or to abandon the stacking concept in favor of a more flexible dependency net (but hey, you can keep drawing it as if it were a stack - nobody is actually checking these things anyway :-).

- nobody should know the UI. That's the generally accepted idea. It's a bit preposterous, given that in many cases the back-end exists only to support the UI, but you can't challenge the notion in guru-driven development. It does not matter that, since the UI is in a web app, and the bandwidth is limited, you need to expose paging at the service level, and probably handle it down to the database level (using your SQL dialect of choice) to keep performance reasonable. You can still pretend that your stack does not depend on the UI if you keep adding enough layers. So, let's pretend nobody knows about the UI.

- the service layer, if distinct from the application layer, has to know the application layer. That's sort of a necessity, because when you split the two, it's to allocate in the service layer all the knowledge (decisions) related to the "delivery mechanism", as Martin calls it, that is, knowledge of your services being exposed as SOAP, JSON, RPC or REST style, etc. But in the end you have to invoke the damn use case / application layer, so the service knows the application.

- is the persistence layer allowed to know the domain layer? Hmmm. This would be a violation of the concept of layers. The persistence layers should only know about one decision (the persistence technology). It should also hide the underlying layers. Unfortunately, to hide the domain layer, it should also expose the domain functions, because the application layer wants those functions. That's not going to work. Of course, if we give up the idea of layers, new shapes are possible. But the gurus want layers, so I won't explore the other shapes.

- at this point, the application layer has to know the domain layer. That's again sort a given, because the application layer is thin and is just somewhat "orchestrating" the domain layer.

- is the domain layer allowed to know the persistence layer? This has been, and in some sense still is, at the center of a long-winded debate.
Proponents of techniques like Active Record and Lazy Fetching naturally think it's ok for a domain object to call into the persistence layer (perhaps without knowing so, through some ORM-generated code) when need arises.
Critics have many arrows to shoot. In practice, I've often observed horrible performance in systems where access to the persistence layer is basically out of control. I'm not the only one to have observed so, of course. Some tried / are still trying to solve the problem by making the whole thing even more complicated. For instance, they try to aggressively cache / prefetch objects, which requires a proper implementation of an identity map, etc. Others have gone with a more simplified approach: the domain layer is forbidden from talking to the persistence layer. It's the application layer which is responsible to mediate between the two. As I said, this actually brings persistence and domain at the same level in the stack, but nobody wants to say so.

In the end, the intended shape of many LoB systems is one of these:

Note that the force that is keeping the application layer and the domain layer apart is reusability (real or imaginary) of the domain layer in case 1, and a more technological separation in case 2.

Thou shall have no stupid objects
Or perhaps thou shall. At some point people realize that we can't easily obtain the shapes above by using intelligent objects.

What is coming out from the service layer, once the details of delivery (SOAP, JSON, whatever) have been removed? Not domain objects, as the service layer has to talk #only# to the application layer.

What is going in / coming out of the persistence layer? Not domain objects, as persistence layer can't talk to the domain layer.

What is going back to the service layer? Once again, not domain objects, because the service layer can only talk to the application layer. Not service-aware classes, as the application layer can't create service-level objects.

So, most naturally, people tend do the obvious thing: they add more classes, totally devoid of behavior, because damn, we have already allocated all the possible behavior in those !@#$ layers. Those classes go by many names, like DTO (data transfer object) or even Entity in some Microsoft-oriented shops (not to be confused with Entities in DDD, of course, just like the ValueObject in DDD should not be confused with stupid DTO-like things). Some (myself included) at some point see the sadness of writing those fake classes and try to adopt hashmap-like things, or dynamic objects in .NET, or whatever. Not a quantum leap, anyway, and fiercely opposed by some people anyway.

The funny thing is that this kind of architecture is often sanctioned by gurus.  You can read what the ubiquitous Robert Martin has to say by starting from here, although it's much clearer if you watch the entire video (entertaining, albeit a bit slow) here. The slides in the first post can get you up to speed quickly (if you can fill the gaps; btw, the ".key" file is actually a ".zip" file).

Martin is actually right when he says that (ideally, at least) the "delivery mechanism", (aka the service layer) should be considered a detail. However, note how quickly he falls into the idea that you need stupid objects to carry around information. Indeed, at some point he declares that "it is ok for objects to simply hold some data". Hmm, ok, if you say so. Except that NO, IT'S NOT OK. Just because you're doing it, or know no better way to get what you want, does not make it ok.

Guru-driven design is dangerous. Gurus have to know best, so if they can't do something, that something is irrelevant. If something they do has consequence, those consequences are ok. For instance, a guru can claim that in DDD is ok to have duplication (entanglement) between two bounded contexts, but not within a bounded context. Now, that's plain wrong, but people will accept it because you're a guru, there is no theory of forces to prove you wrong, and unlike in the physical world, the material won't react in a powerful way when you're wrong (try to negate the existence of gravity by jumping out the window instead :-). Of course, the guru could instead say that it's just the best trade/off he knows, but that's less guru-ish than ideal.

The actual danger is that people will stop trying. After all, the gurus say it's ok. So there is no need to explore new materials (AOP, a mixin revival, structural conformance, whatever) or to explore new ways of shaping traditional materials (as I'll do in a moment). It's very much like having a guru saying that it's ok for a bulletproof window to be totally opaque, because he doesn't know how to make bulletproof glass. Except that I don't like the idea of people spending life in darkness. So, sorry, it's not ok.

In this corner... the mapper!
Of course, when you condemn smart people to a never-ending pile of layers, all entangled on the same domain concepts, passing around stupid data structures, they can't just pretend not to see it. They won't challenge your architecture, because you're the guru, but they'll try to avoid some drudgery by writing smart code.

For various reasons, the only techniques with a dim chance of success here are reflection and generative techniques, and at some point everyone comes up with a concept of Mapper (emphasis on -er), something that can somehow find "equivalent" fields in similar object and clone them. Given enough motivation, these things get beefed up and turned into full-fledged libraries, for popular joy.

Introducing "mappers", hopefully semi-automatic classes, provides some relief for coders, but is only a coping technique. For instance, run-time friction kicks in anyway. In a very interesting dissertation (Analyzing Large-Scale Object-Oriented Software to Find and Remove Runtime Bloat), Guoqing Xu found that a lot of inefficiency stems exactly from long "copy chains". Does it ring a bell?

Still, I don't want to challenge the established architectures, so here is the modest contribution of this long post: to tell you guys a possible way to keep those layers but let go of stupid objects (and henceforth of mappers). I don't claim originality: it's very possible that many of you guys are already using this style. I came up with this a few years ago, mostly while trying to mediate between the desire of some of my clients to go with the "standard" layered architecture and my disgust for stupid objects. I haven't seen this style adopted and pushed to its real potential elsewhere, but it's totally possible that it's commonly adopted by some and that I just had no chance to see it used. It's based on the semi-layered architecture where the domain layer can't see the persistence layer, but is a very general idea.

On truly understanding your material
An important concept in the physics of software is that we have run-time things (like objects, with their memory footprint, and actual function calls, with parameters being passed and CPU cycles eaten) and artifacts, like source files, where we describe those things, their structure, their behavior.

In practice, we expect some run-time properties and some artifact-side properties, but traditional literature has never taken time to explain where we want something to happen. For instance, where do we want layering to happen? Where do we want isolation of change? We want that on the artifact side, of course. When a decision changes, we want to change only one folder of source files (layer). We may also want to reuse an artifact elsewhere, as a source file or as a compiled library or as an executable. We actually don't care about run-time separation at all (to some extent - I'll add something about this in the "critics" section).

Still, people (including gurus) tend to get trapped into a linear form of thinking. If artifact A (say, an Application-level class) can't talk to artifact P (say, a Persistence-level) class in terms of class D (say, a domain-object class), then I have to introduce another class, and therefore, a new run-time object has to be created and then "mapped".

In fact, the emergence of stupid DTOs as a consequence of separation of artifacts is largely due to an underlying (wrong) assumption: that artifact separation requires run-time separation. This, however, is far from true, although it may require different programming techniques, depending on your language. From another perspective, the idea may suggest useful concepts we may want to be supported by our programming languages - this is akin to Materials science, and the idea of creating a new material based on the forces it has to withstand; contrast this with how many languages are created, based on notions of "purity" instead of a sound theory of forces.

Application talking to Persistence without DTOs
Say that you have an Application object, and this object has somehow obtained a Domain object (we'll see how in a moment). Say that you want to persist the Domain object, but unfortunately, the Persistence layer can't know about your Domain object in a layered architecture. Is there anything better than creating a DTO by basically cloning the Domain object (and then claiming that it's ok to have stupid objects)?

Well, if you think about it, while it's not ok for an object to exist only for the purpose of containing data, a Domain object may want to offer an interface to read some of those data. After all, when we accepted technology as a principal decomposition, we also accepted some kind of entanglement on domain concepts, and that interface is there exactly to represent the R-entanglement we got.

Suppose I've got a User class (a domain concept) with some domain logic, like telling me whether or not today is the user's birthday. I could easily do this (example in C#, but without the I in interfaces, so it looks like Java :-)

// the R-entanglement interface
interface UserData
{
  int Key { get; }
  DateTime dateOfBirth { get; }
}

// the Domain/Business object
class User : UserData
{
  // UserData implementation stuff

  // some business logic
  public bool IsBirthday()
  {
      // ...
  }
}  

// the Persistence layer, using the Repository pattern
class UserRepository
{
  public void Store( UserData u )
  {
    // I just want to read the data and issue an insert
  }
}

well, that was easy. Just because I don't want my Repository to depend on my domain object, doesn't mean I have to clone data before I pass it in. I can just use an interface (which does not need to live in the Domain layer).
Things get much harder the other way, though, and I guess here is when people turn back to DTOs:

class UserRepository
{
  public UserData Get( int key )
  {
    // ????
  }
}

Of course, it's not enough to give UserData the "set" method for properties. Of course we have to do that, but the real issue is that my repository has to create the object, and you can't create an interface, and you don't want to create a domain object inside the repository (because you don't want to know the domain object). Note that even creation alone (without usage) would break the layer shape, if you need to put a dependency between your artifacts.

Now you need to know your material well enough to solve this problem, as there is no language-independent solution. I'll give you the C# solution; in C++, you can basically use the same thing (you don't even need the interface as it is inferred). In Java you can't, so you have to bring in the heavy artillery, but most likely we're gonna do it in C# as well (more in a minute).

class UserRepository
{
  public T Get< T >( int key ) where T : UserData, new
  {
    // ... get data from the database
    T u = new T();
    // fill u with data (needs "set" methods in UserData)
    return u;
  }
}

and usage in the application layer would just be:

class MyWonderfulUseCase
{
  public void DoSomethingUseful()
  {
    // ...
    User u = userRepository.Get< User >( key ) ;
    bool b = u.isBirthday(); // u is a full-fledged domain object :-)
    // ...
  }
}

Look ma, no stupid objects. No mappers. No unwanted dependencies between layers (as artifacts). No friction. No hashmaps. All type safe. No casts either.

What was that?
Forget the language for a moment. All I did was to separate the artifacts without separating the instances (run-time things). I did that through interfaces + generics, because in C# and C++ generics / templates are powerful enough for this sort of things. But generally speaking, what I want to do is:

- define an interface to access data (or two, if you want read/write separation).

- communicate between layers in terms of that interface (removing the need for a DTO).

- define a mechanism for the "lower layer" to create objects in the "upper layer" without having to know their classes. In this case, I used generic programming.

Generally speaking, you may want to use an Inversion of Control Container instead. Besides working in Java as well, the IoC will be helpful in a variety of cases (like handling inheritance) where generics just won't work. In this case, the code above would become something like (using Unity in C#):

class UserRepository
{
  public UserData Get( int key )
  {
    // ... get data from the database
    UserData u = Container.Resolve();
    // fill u with data (needs "set" methods)
    return u;
  }
}

There is another reason to switch to an IoC: the generic version is a drag when your objects contain other objects which contain other objects and they all come up with a single query, perhaps through a stored procedure. The IoC has no problems with that. The generic version requires you to specify all types in the instantiation, which is not so nice (but not an insurmountable problem in many cases).

Note, however, that by removing the generic parameter, I have abstracted things a little too much. I wanted a User, but I'm getting back a UserData. So my application code would become:

      User u = userRepository.Get( key ) as User ;
      bool b = u.isBirthday(); // u is a full-fledged domain object :-)

which may not look like a cast, but is cast anyway. This can be fixed to some extent, if you add another interface on top of your domain class (which could still be useful for mocking) and combine the generic version above with the IoC. You'll still have a cast, but only in one place (the generic function).

Of course, the gurus will readily tell you that your architecture should not depend on an IoC. That's a rather narrow view of things. I don't need an IoC. I could go with a factory. I also don't need polymorphism. I could go with function pointers. Except I'm using polymorphism, thank you. I'll also be happy to use a language-provided mechanism once you get me a decent one :-). In fact, the idea that most programming languages don't readily support decoupling instance creation from class name at the artifact level is appalling, and it's just another sign of why we need a physics of software. The IoC is a superstructure. I want an infrastructure.

In practice, moving outside this limited case, it would be even more beneficial to have mixins, so that we can mix behaviors into an object. I need run-time mixins though. This is a long story and perhaps I'll say something about it in the future, probably using the only widely adopted language I know where I can express those things (Javascript: ain't that ironic? :-). The design space out there is far less constrained than the usual gurus may lead you to believe. Don't fall into habit. Think think think.

What about the other "mappers"?
Or about the other stupid objects? If you look at Martin's example, for instance, he has a ResponseModel class (actually, many: at least one per service) carrying only data. In practice, we tend to fall into one of these cases:

- that class is basically cloning the interface of some business object. There is no smart to add because the infrastructure will take care of the rest (for instance, in a .NET WebApi service, the JSON serializer [sic] is smart enough to send back my stuff without me adding behavior. Therefore, pass back the xxxData interface instead, or the read-only version if you like so (you may recognize this as similar to storing something by passing a read-only interface, as above; after all, why should these two things be different at all?)

- there is significant behaviour that could be allocated there, but it's on the service side. For instance, the class represents an error, and you want to convert it into an HTTP status + some json, and you need custom code. It's exactly the same issue we have between Persistence and Domain, except that now is the Application which has enough information (the error, the message) to build the object, but can't create the object because its class lives across the border. Just use the same trick: get a writeable interface from your IoC (or whatever), fill with data, pass the thing to the Service layer, which will happily cast it to an intelligent object. Here I think a cast is unavoidable (and no, I'm not weeping in fear).

How do you pass data from the service layer to the application layer is left as an exercise for the reader :-). In practice, this depends a lot on your technology stack, how far is already trying to go (model binding) and how well does it play with interfaces, IoCs, and the like. If it doesn't, I would say it's more of a limitation of a specific implementation than a fault of the general principle. Of course, some guru will tell you that your Model is not your Domain, and that you need just another layer. Oh well. Where is YAGNI when I need it?

Critique
In practice, I've heard three distinct critiques (plus one):

- it requires an IoC. Funny enough, this is usually coming from people already using an IoC :-), but for other, more guru-sanctioned things like instantiating a logging service (which they never ever change). As I said, I don't need an IoC. I need a flexible way of separating creation from static knowledge of a class name. The IoC is just a reasonable way to get that.

- I may then call business logic inside the persistence layer (as I'm creating a business object). Yes, but we'll spot you as you'll have a dependency on the business package. Sure, you can try to defeat the checking through reflection. But then, you can always load an assembly at run-time using reflection as well. As good Bjarne used to say, we want to protect ourselves from Murphy, not from Machiavelli.

- I don't mind writing all those structures and mappers. It's simple code. It's relaxing. Now, this may sound stupid, and I can honestly say that I felt like saying something very impolite when I first heard this argument. On retrospective, I understand the feeling. Technically, it's work, but it's rote work, so you can turn off your brain for a while, and nobody can say anything because hey, someone gotta write that code. In a high-stress environment, having something brainless to do can give you a legitimate break. That said, I don't like the argument, because it's corrupting the design to cope with a problem in a very different area (management). It's not my style, sorry.

- a small variant to the above is that I'm leaving some choices open (like, should I return a readable interface to the service layer, or create a service-layer instance from the application layer using an IoC). What's worse, I'm not mandating a style: you may want to use one thing or the other, depending on context. But that requires you to think, which is the opposite of the brainless coding above. Sorry. I'm into #braindrivendesign. There is no way around that :-).

What about testing? Right, someone has gotta play the T card at some point (this is the "plus one"). But actually, this technique plays very well with all your testing needs, as everything is interface-based and can be easily mocked. You don't need stupid object to be test-friendly.

However, I'd like this post to contribute to Brain-Driven Design, not to Guru-Driven Design. So, don't do this just because I said so. Just remember it can be done; you may not have tried this shape before: give it a try when you see a good fit, and see what happens. If, instead, you find yourself thinking "no no no no" and spending all your mental energy trying to find faults in this techniques, and not a single moment pondering on what's good, well, as I said above, it could be a nice step into self-awareness to stop and think why (I did this exercise many times in my life :-).

The end
Honestly, I don't think the layered shape is a good fit for LoB applications. As I said, very few systems can be built with a real layered shape, and most often, there is a significant difference between what is told/drawn and what is done (code). The most natural shape for OO systems is a network of services, and a very interesting thing would be to redefine the database as a provider of services, not merely data. This would also be more aligned with the need of distributed technologies and map / reduce (and therefore, make your [ex]persistence layer more robust in face of technology changes). It's actually easier than you think, and sometimes all we need is a small change in our queries. I'll touch on this in my next post, provided I don't forget :-).

Still, even with the heavy constraints of a semi-layered architecture, we can avoid stupid objects without losing separation of concerns (which is an artifact thing, not a run-time thing). Note that I didn't push (as some have done over the years) any presentation responsibility into the business objects (yes, a RenderInXml method is still a presentation responsibility). I've kept the same separation of concerns we have in traditional, DTO-based systems.

In the end, although I hope you guys enjoyed this post, I wrote all this just so that next time I'll be able to write code where domain objects come freely out of repositories, without being accused of breaking separation of concerns. So, next time I'll go back to the forcefield, and see what is telling about our unstable User class :-).

If you read so far, you should follow me on twitter.