Home > .NET Domain Model, Developing Using CodeFluent Entities, Presentation > CodeFluent Entities: Standing Against Anemic Domain Models

CodeFluent Entities: Standing Against Anemic Domain Models


A few years ago Martin Fowler wrote this great post regarding what he calls “Anemic Domain Models”:

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

That’s exactly what we try to avoid: those business logic empty classes, often wrapped in an extra layer of procedural services, which in the end just create a procedural style design. Furthermore, many people think that anemic objects are real objects, thus completely missing the point of what object oriented design is all about.

image

Instead, as Eric Evans states about the Domain Layer (or Model Layer):

Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

And we completely agree: especially right now, on the verge of a new technology wave (e.g. HTML5 & WinRT) the real key is your architecture. If you already have this rich domain layer, upper layers should just be consumers of it, empty shells providing user interaction to the heart of your business software. Consequently supporting a new platform (going from desktop to web, or Web Forms to MVC for instance) gets down to creating this new shell.

That’s what CodeFluent Entities is all about thanks to it’s .NET Business Object Model Producer: it generates a full .NET domain layer containing your business logic and which can be used across all .NET technologies (Windows Forms, WPF, SharePoint, ASP.NET MVC, ASP.NET Web Forms, Windows Workflows, etc.) this way securing your investments.

This is possible as this producer (= code generator) can generate:

  • Classes: plain old classes (not deriving from a base technical class), human readable, that are all partial and meant to be easily extensible by developers, implementing an extensive set of interfaces (ICloneable, IComparable, IDataErrorInfo, IEquatable, INotifyPropertyChanged, etc.) to ease development of upper layers, and easily debuggable as no code is dynamically generated at run time
  • Enumerations: since CodeFluent Entities is not an ORM, you can create your own .NET enumerations or reuse existing ones,
  • Multiple namespaces: as it’s common to have more than a single domain in real enterprise class applications,
  • Rules: to validate your data, set-up transactions, and implement your business logic,
  • Methods: create your own methods aside default generated ones,
  • light objects as structures or non-persistent objects useful to gather-up cross entity information,
  • components as a binary large object http handler to manipulate blobs in web environments, or a cache manager based on the standard ASP.NET cache manager, and more.

Last but not least, we don’t think that tools can generate entire enterprise-class applications, that’s not what we’re saying. Developing applications is a complex operation that needs more than data access and/or UI controls. Instead what we’re saying is that we provide a tool to developers which helps them set-up rock-solid foundations for their .NET applications, built on a consistent domain model, which developers will have to extend and fill-in the gaps.

The recipe we provide through CodeFluent Entities ends-up creating .NET applications based on a rich Domain Layer built by the tool and developers, containing the full business logic of your application. It’s a complete and consistent API which can be used on all platforms (x86, x64, desktop, web) across all technologies (.NET 2 to 4) this way securing your investments.

Carl Anderson

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 51 other followers