SoftONELogic Alliance Network

This article is taken from the discussion between me as software engineer with the team leader plus IT Manager.

In mid 1995, Object Oriented Programming concept is widely accepted in the software development. When internet starts to grow, there were a lot of new software development methodology appear in the software development world.

But, a lot of them are constrained by the technology. We must follow the code implementation based on the technology used. For example Enterprise Java Bean. There are rules how to implement our logic in the EJB based technology. We need to follow the rule about how to create a class to be ‘publish’ as Stateless Session Bean, Statefull Session Bean, Entitiy Bean, etc.

People start to leave the design part, they more concentrate in technology part of software development phase. Domain Driven Design is trying to bring back the  software developer from technology constraint to the design.

The Domain Driven Design series article try to elaborate more about what is Domain Driven Design and how to implement DDD in software development phase.

To be honest, me, myself, still new in DDD. I know how to implement 3-tier architecture: Presentation Layer, Business Logic Layer and Data Access Layer. But when new layer is introduced to me, Domain Layer, I need to learn how the Domain Layer will be ‘inserted’ in the 3-tier architecture. I will update this article during the DDD training in my software project team.

4 days later….

After a week attended the training, i was wrong in the previous paragraph. The domain layer is not ‘inserted’ to the 3 layer architecture. It’s totally different concept.

Domain Driven Design is an approach of software design that is focusing on the domain model among other things. Why DDD? The application is built for a domain-centric business.  If team size is small, DDD is suitable to be implemented since  the development can be tested in the domain layer. So it is important to balance the need to build a scalable software, and yet avoiding an overly complex architecture.

Domain Driven Design Characteristic

• Domain Model is the center piece of the application. It should not be aware of any underlying technology built around it.
• Domain Model should be Persistence Ignorance.
• All business rule should be contained in the Domain Model
• Business entity is modeled as: Domain Object if identity is important or Value Object if identity is not important.
• Domain Object is organized via Root of Aggregate
• Each Root of Aggregate is accessed via a Repository. The implementation of the Repository will take care of the persistence.
• If there is any business rule that is not suitable to be put under any Domain Object or Value Object, then it will be moved into Domain Service.
• Aggregate might be instantiated via Factory object.

But wait, what are the meanings of those jargon above? Ok, I will explain in the next post.

references:

Charlton, C.(2009). Domain Driven Design: Step by Step Guide
R.B.(2009).DDD Training Material