DDD or not DDD ?
Uncle bob said : “The Goal of software architect is to minimize the human resources required to build and maintain the required system”.(Robert C.Martin)
Domain Driven Design
I often use terms that people associate with Domain Driven Design (DDD), however, I generally don’t call out Domain Driven Design explicitly in many of my videos or blog posts. You probably have noticed that I do talk a lot about boundaries. Boundaries are probably the most important aspect for me that came from Domain Driven Design. However, the vast majority of content or discussions you will find online about DDD revolve around tactical patterns: Entities, Value Objects, Repositories, Services, Aggregates, etc.
While the tactical patterns have value, they must come after understanding the concept and value of defining boundaries with a Bounded Context. While a Bounded Context does get a lot of attention from Domain Driven Design enthusiasts, it’s not what people are introduced to first in tutorials or “sample” applications.
Here are some of the comments and questions I see the most related to Domain Driven Design:
DDD is only powerful when your business logic is complex
While I agree complexity is a driving factor, I also think it’s helped me most when dealing with larger systems. Complexity from the Domain as well as the complexity that comes from a large system.
In DDD you’re supposed to use a repository pattern.
You need to use factories to create entities or value objects.
This is the wrong concern. Focusing on patterns rather than boundaries and modeling the actual domain.
You have no logic in your entities, so that’s an anemic domain model, which is an anti-pattern.
It’s only an anti-pattern if you think you have a domain model but you really have a data model with transaction scripts. There isn’t anything wrong with starting with that and moving to a richer domain model as your understanding of the problem evolves.
You can’t have dependencies in your Domain Model
Should you use Domain Driven Design?
If you’re developing a large system that has complexity at the heart, then yes, I recommend looking at some of the strategic (and tactical) patterns from Domain Driven Design. If you’re defining boundaries around capabilities and language (bounded context), guess what? You’re already doing Domain Driven Design!
If you’re writing a relatively small application without much complexity, don’t get caught up with trying to apply the tactical patterns.
Based on uncle bob we have 2 below chart, these are show in long time number of line of code don’t change but number of developer increase.
these are show in long time productivity decrease in large code.
Complexity of domain login martin fowler
Martin Fowler in the Pattern of Enterprise Application Architecure book talk about 3 item for show complexity of Domain Login.
- Transaction Script
- Table Module
- Domain Model
Transaction Script
Transaction Script (TS) is the simplest domain logic pattern we can find. It needs less work to implement than other domain logic patterns and therefore it’s perfect fit for smaller applications that doesn’t need big architecture behind them. This posting focuses on TS pattern by illustrating and analysing it. Also some good hints for implementation are provided.
Example
Imagine application that provides some functionalities:
- load orders to deliver,
- generate invoices,
- calculate bonuses for customers.
These functionalities can be handled as two transactions: generate invoices, calculate bonuses. We cań create classes to handle invoice generating and bonus calculation but we can also go with one class that provides both methods. It’s up to you to decide which is better for you.
class InvoiceGenerator
{
public void GenerateInvoices()
{
load orders to deliver
iterate through orders
generate invoice
mark them ready to deliver
}
}This example uses one class for all operations. If you have many operations then use multiple classes to organize code better.
Where I use TS?
I have used TS mainly in small applications where I really don’t want to apply any bigger architecture. TS will save you a lot of time when applied in correct context. Some applications where I used TS are:
- Estonian ID-card based door lock control — Windows service and simple Windows Forms applications that allow to manage users, give permissions for opening doors and see who and when opened the door. It may sound like big application but the actual complexity lies in hardware and the software I wrote is actually very simple.
- Jira importer — my company uses small service that imports work logs and tasks from Jira to our main database where programming work, sales and billing meet. Getting data from Jira can be tricky but still this service is simple enough to avoid more complex patterns.
On both cases I got simple classes that provide some functionalities needed by applications and it took less time than implementing full domain model by example.
Tips
- TS works well for small applications that doesn’t implement any complex logic,
- When used in bigger applications TS has problems like code and functionalities duplication between procedures. If you see application growing then switch to some other domain logic pattern that is better fit for your application.
- It’s not easy usually to refactor TS to other domain logic patterns as other patterns deal more or less with classes that represent some business entity.
- In TS you can use different data source patterns to access and manipulate data. In my door lock control system I used ADO.NET objects. My Jira importer uses simple Entity Framework classes.
- When building your TS classes you can also apply design patterns to organize code better. Don’t let your TS classes grow to big bad spaghetti code.
- Don’t make TS classes dependent on presentation layer classes because dependencies like these makes it harder to share those classes between applications and also testing of TS classes will be very hard this way.
Table Module
A single instance that handles the business logic for all rows in a database table or view.
One of the key messages of object orientation is bundling the data with the behavior that uses it. The traditional object-oriented approach is based on objects with identity, along the lines of Domain Model (116). Thus, if we have an Employee class, any instance of it corresponds to a particular employee. This scheme works well because once we have a reference to an employee, we can execute operations, follow relationships, and gather data on him.
One of the problems with Domain Model (116) is the interface with relational databases. In many ways this approach treats the relational database like a crazy aunt who’s shut up in an attic and whom nobody wants to talk about. As a result you often need considerable programmatic gymnastics to pull data in and out of the database, transforming between two different representations of the data.
A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.
Domain Model
A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.
A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
Conclusion
Based on article and charts Martin Fowler and Uncle bob in their own book show that Domain Model Pattern is one of best architecture for large scale application and all big application must develop based on Domain Model.
