Domain Driven Design

Domain Driven Design notes

• complements MVC

• separates the model layer ("M") of MVC into:

1. an application tier - used to retrieve and store data
2. a domain tier - where the business knowledge or expertise is
3. an infrastructure tier - responsible for coordinating the infrastructure and domain tiers to make a useful application

Entity

You can use than base entities as they are, or you can extend the base entities with additional methods that encapsulate business logic. For example, there is an Invoice base entity class with fields such as invoiceId, invoiceDate, referenceNumber and accessor method such as getInvoiceId(), setInvoiceId(String invoiceId), etc. Then, there is an Invoice class in the billing domain which extends the base Invoice class and has methods such as getInvoiceTotal(), getAppliedAmount(), etc.

Infrastructure

The Infrastructure class is a global directory of infrastructure resources, such as database access connections, located across all the frameworks and platforms of opentaps. Initially, it can be used to obtain the delegator and dispatcher of the ofbiz framework, but as more applications are added to opentaps, it will also return the infrastructure their frameworks require, including JDBC connections or hibernate session factories. These infrastructure resources are passed to the Repository and the Factory classes so that they can interact with the database and external Web services.

Factory

The Factory class is designed to create Entity objects based on other parameters. For example, you might want to create an Invoice Entity based on customer and invoice terms, or you might want to create an Invoice Entity based on an existing Order, taking its customer and list of items as a starting point. The Factory class is meant to be extended to create Factories for the different domain aggregates such as Invoice, Customer, Order, etc.

Repository

The Repository is designed to help retrieve and store Entities and is meant to be extended for the major Entities, so the foundation Repository should be extended to CustomerRepository, InvoiceRepository, and OrderRepository to support Customer, Invoice, and Order Entities.

As a good design pattern, a repository should fetch objects directly and not associations. The modeling details of a particular implementation should be hidden from the domain.

Repositories or Factories?

Factories are intended to create new Entity objects, while Repositories are intended to retrieve and store them. Therefore, we would follow the following rules for Factories and Repositories:

1. Use Factories for create and Repositories for get and store
2. Always return the domain's Entity object from your Factory, so it looks like a real object Factory
3. Factories will almost always use the service dispatcher, whereas Repositories will usually use the dispatcher but may sometimes use the delegator

Services

Services are designed to encapsulate business logic that span multiple Entities, such creating Invoice from an Order.
Parameters for your service are passed into your service via set methods, the execution of your services via a void method, errors are propagated by exceptions, and the results of your service are passed back via get methods. This is in contrast to the ofbiz framework, where services are defined as static Java methods (don't ever write one in minilang!), the parameters are passed in a map, the results and any error messages are returned in a map.

Because these services are Java objects, we follow the convention to group services with similar parameters together into one class. For example, all services which create Invoices from Order should be in one class, and all services which create Invoices from Shipment should be in another. This allows them to share set and get methods without having one service class which is too long.

What domain should a service be a part of? By convention, we recommend that the service is part of the domain of its output, so all services which create Invoices should be part of the Invoice domain, whether the invoices are created from orders, shipments, or recurring agreements.

ver conferencia de Eric Evans sobre DDD

Enlaces y Recursos Domain-Driven Design

http://tech.groups.yahoo.com/group/domaindrivendesign/messages