Architecture – Domain Model Design – Best Practices for Robust Fluency, Encapsulation, and Extensibility

Architecturedesign-patternsdomain-driven-designdomain-model

I am striving to have the most maintainable architecture possible in my application, but I cannot decide on a proper domain model design.

Here is an example domain model for a user:

public class User // Referred to as the domain model
{
    // A model whose properties map exactly to a database table schema 
    private UserDataModel Model { get; set; } // Posts data back to the database

    public string FirstName
    {
        get
        {
            return Model.FirstName;
        }
        set
        {
            // Validation & Observer logic here
            Model.FirstName = value;
        }
    }
    public string LastName
    {
        get
        {
            return Model.LastName;
        }
        set
        {
            // Validation & Observer logic here
            Model.LastName = value;
        }
    }
    public string FullName
    {
        return $”{FirstName} {LastName}”;
    }
    public Company Company // Other domain model with a similar design
    {
        get
        {
            return Model.Company;
        }
        set
        {
            // Validation & Observer logic here
            Model.Company = value;
        }
    }

    // List of other domain models with similar designs
    public IList<Order> Orders { get; set; } 
    // …

    internal User(UserDataModel user)
    {
        Model = user;
    }

    // Domain specific methods here 
    //(e.g. IsAdmin, CalculateBill, SendPasswordResetEmail, CanPlaceOrder, etc.)
}

Essentially, my concerns relate to what are the best practices for having an effective, efficient, and maintainable domain design that allows for robust consumption, strong encapsulation, and high extensibility / maintainability or scalability. Specific questions are:

Properties

a) Should my domain model contain properties similar to the underlying data model or properties that are only relevant to the application’s consumption of the domain model (i.e. properties like FullName, boolean flags like Dirty (updates occurred), Prototype (i.e, brand new dummy model for creation by client/consumer))?

b) Should the underlying data model be exposed publicly for access or should it only be accessible via methods? Should only parts of the data model be returned or the entire object?

c) Should the domain model include linked objects (i.e like the Company object in the example) or just the relevant value to that linked object (i.e. the Name property of the Company object instead of the entire object)?

d) Should setters be similar to above or only via methods called on the domain model or private methods called in the property setter (i.e. set { SetFirstName(value); } )? (Note: The setters will implement validation engine calls & observer calls & service calls, so they will be relatively chunky)
Construction

a) Should I approach construction of a new domain model from the client/consumer via several set methods or purely mapping the properties at the client/consumer level or via a factory / builder pattern?

b) Should my domain model completely hide the underlying data structure it represents (i.e. appears as if it is a object that was never part of a database)?

c) Should validation be done at construction level (i.e. as properties are set) or left up to the client/consumer calling an “IsValid” method on the domain model when appropriate?
Validation

a) Should validation errors be stored in a collection in the domain model or in a separate errors model / singleton class?

b) Should validation be done at the domain model level or data model level?
Retrieval

a) For lists of objects (i.e. orders), should the list be private and access via a “GetOrder(string orderNo)” method? Wouldn’t this be a violation of the Single Responsibility principle (I.e. the method is a pseudo repository / factory) or no?

b) How should retrieving an entire list be done without affecting the containing domain model or the domain models in the list? Should a clone be used despite it being potentially memory intensive (a user could have thousands of orders with their own linked domain models)?

I am ideally trying to avoid developing an unmaintainable domain design that is a pain to consume or test. I want the domain model to be as fluent & robust as possible thus allowing it to be read like prose to the client/consumer and representing the actual domain not the underlying data structures (i.e. it should be able to act as if it standing on its own without a backend).

Best Answer

Frankly, glue classes that merely pass through fields from the data model don't really add significant value to your application, nor are they particularly interesting from a functional perspective.

So before we get too deeply into your individual questions, let me propose a simple foundational architecture:

DB <---> ORM <---> SL/BLL <---> VM <---> V

The DB is your database. The ORM is your Object-Relational Mapper; it communicates with the database via SQL, and exposes CRUD methods. The SL/BLL is your Service Layer/Business Logic Layer; it converts business operations such as CreateInvoice into CRUD methods for consumption by the ORM. The VM is the ViewModel; it coordinates UI interaction with the SL/BLL. The V is the View; it contains surface-level UI interaction and validation code-behind.

Your sample code is suggestive of C#. In C#, your ORM (very likely Entity Framework) can produce code-generated entity classes that can be glued to domain logic using the partial keyword, allowing you to write custom domain and validation logic for each entity class without the pain of creating all that boilerplate for DTO's.

A lean architecture like this one should allow you to develop an easily maintainable application with the minimum necessary boilerplate code. Unless you're building an elaborate, crystal-cathedral architecture in Java for a large development team, this representative architecture should be all of the abstraction you will ever need.

Related Solutions

Encapsulation in Domain Driven Design models

There is a fundamental difference between your Data Access Object (DAO) and your Business Object (BO). Your DAO is a one-to-one mapping of what your data store looks like. In this case, for your AccountDAO object, the AccountNo and Balance properties will have getters and setters. Your Account object - the business layer objects - will not look the same as your DAO.

// This is a DAO
public class AccountDAO {
   public string AccountNo { get; set; }
   public decimal Balance { get; set; }
}

// This is a business object
public class Account {
   private readonly string accountNo;
   private readonly decimal openingBalance;
   private readonly List<decimal> adjustments; // This should probably be a list of transactions.

   public class Account(string accountNo, decimal openingBalance) {
      this.accountNo = accountNo;
      this.openingBalance = openingBalance;
      this.adjustments = new List<decimal>();
   }

   public string AccountNo {
      get { return accountNo; }
   }

   public decimal Balance {
      get { return openingBalance + SumOfAdjustments(); }
   }

   public void Deposit(decimal amount) {
      adjustments.Add(amount);
   }

   public void Withdraw(decimal amount) {
      decimal testBalance = Balance - amount;
      if (testBalance < 0.0m)
         throw new AccountBalanceException("Account Balance for " + accountNo + " is less than $0.00.");

      adjustments.Add(-1.0m * amount);
   }

   private decimal SumOfAdjustments() {
      decimal sum = 0.0m;
      foreach (var adjustment in adjustments) {
         sum += adjustment;
      }
      return sum;
   }
}

// Let's come up with a good way of performing actions on an account.    
public class CashDepositActivity {
   private readonly Account account;
   private readonly decimal amount;

   public CashDepositAction(Account account, decimal amount) {
      this.account = account;
      this.amount = amount;
   }

   public void ExecuteAction() {
      // You should probably have some logging here.
      account.Deposit(amount);
   }
}

public class BalanceTransferActivity {
   private readonly Account sourceAccount;
   private readonly Account targetAccount;
   private readonly decimal amount;

   public BalanceTransferActivity(Account sourceAccount, Account targetAccount, decimal amount) {
      this.sourceAccount = sourceAccount;
      this.targetAccount = targetAccount;
      this.amount = amount;
   }

   public void ExecuteAction() {
      sourceAccount.Withdraw(amount);
      targetAccount.Deposit(amount);
   }  
}

This is just an example, of course, and it is by no means an end-all solution. I know tools like EF have myriad examples where the data object, business object, and view/edit object are all the same object, passed from the database to view. In my experience, that works great on small projects where there is not a lot of business logic. However, it breaks down as your business rules and access restrictions grow in complexity.

Architecture – Validation and data persistence in a domain model

I could be mistaken in my understanding, but I believe your trying to redesign your Domain Model so that it isn't riddled with anemia. A couple of really, really great books on the matter are:

Martin Fowler - Patterns of Enterprise Application Architecture
Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart Of Software
Vaughn Vernon: Implementing Domain Driven Design

They have a lot of content which answers quite a few questions on your goal. One of which is:

A rich Domain Model can look different from the database design, with inheritance, strategies, and other Gang of Four patterns, and complex webs of small interconnected objects. A rich Domain model is better for more complex logic, but is harder to map to the database.

A simple Domain Model can use Active Record, whereas a rich Domain Model requires a Data Mapper. Since the behavior of the business subject to alot of change, it's important to be able to modify, build, and test this layer easily.

That is an excerpt from Fowler. He will go into details about the model being anemic and bloated models as well. The scope of the question to me appears quite large; so I'm not sure I could delve far into it. Those books should point you in the right direction; also will allow you to gauge your current project and implementation to refactor it quickly.

From a relatively basic understanding:

You should be able to abstract your model, which will allow a brief overlay of the UI and Data Access into your Domain Model. But otherwise the model should allow a clear, clean, concise implementation which will help separate responsibility.

Sorry I couldn't be more help.

Best Answer

Related Solutions

Encapsulation in Domain Driven Design models

Architecture – Validation and data persistence in a domain model

Related Topic