Question: I try to abstract my specific domain problem to a banking account, assume the following situation:

* I have an Banking Login of a certain customer.
* Each Customer can have multiple banking accounts which belong to the same login.
* Each banking account can have thousands of transactions.

I designed the class structure as folows (simplified):

```
public class Login
{
    private List<Account> _bankingAccounts;
    ....more fields, ctor, getters, setters...
}

public class Account
{
   private List<Transaction> _transactions;
    ....more fields, ctor, getters, setters...
}

public class Transaction
{
   String _comment;
    ....more fields, ctor, getters, setters...
}

```

Well, but If I have let's say 20 Account and each has 10000 transaction and I load the entire model from the database there would be a large amount of memory, even I don't know if the customers needs all these transactions.

I thought to build a more simplified model like this:

```
public class Login
{
    private List<SimpleAccount> _bankingAccounts;
    ....more fields, ctor, getters, setters...
}

public class SimpleAccount
{
    ....more fields, ctor, getters, setters...
}

public class Account
{
   private List<Transaction> _transactions;
    ....more fields, ctor, getters, setters...
}

public class Transaction
{
   String _comment;
    ....more fields, ctor, getters, setters...
}

```

Then I would load a account model with simplified Account (which does not contain all the transaction) and only i the user requests to see the transaction of a specific account I will load this single entire Account object.

Would that way be ok? Is there a better approach?

Answer: 
When you structure your *domain* model you should not think about performance implications, because domain model is what your domain is, not necessarily what you implement.

Besides, if you use any decent ORM framework out there (for example, [entity-framework](/questions/tagged/entity-framework "show questions tagged 'entity-framework'")) you can load from DB only the data you need, not entire object graph.
There's a pattern called Event Sourcing that sounds like it might help you. It relies on the storing of events (in your case these are the transactions) instead of a running total so you can do more with the data.

This pattern hits the same problem you have encountered. So there's an addition to this pattern called Snapshots. Taking a Snapshot, say at the end of each month, would allow you to take a point in time and load transaction records back to the closest snapshot. The snapshot would show the account as-it-was at the point of the snapshot (probably the product of the last snapshot or account opening event with all the transactions in between replayed).

If you Google 'Event Sourcing Snapshot' there's plenty of article discussing the pattern. Hope this helps.