SoftONELogic Alliance Network

Layering in software architecture

Creating programs that can handle very complex tasks calls for separation of concerns, allowing concentration on different parts of the design in isolation. At the same time, the intricate interactions within the system must be maintained in spite of the separation.

One of the function of layering in the software architecture is to make the relationship between layers to become as loose coupling as possible. In the three layer architecture, the user interface will be handled by Presentation Layer. Presentation layer responsible for the display of required form element and data from database. All business logic will be handled by Business Logic Layer. Accessing database will be handled by Data Access Layer. The usage of interface will make the relationship of each layer loose coupling.

Problem in 3 layer architecture

Even though there are separator between layers, there are still some problem need to take care in the 3 layer based development. If we talk about business logic, it should be handled by business logic layer. But in practical, sometime the business logic will lies in the data access layer through the usage of stored procedure.The question is, who control the design of the software?

Layering in DDD

The value of layers is that each specializes in a particular aspect of a computer program. This specialization allows more cohesive designs of each aspect, and it makes these designs much easier to interpret.

User Interface (or presentation layer)

Responsible for showing information to the user and interpreting the user’s commands. The external actor might sometimes be another computer system rather than a human user.

Application Layer

Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems.

This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
 

Domain Layer

Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

Infrastructure Layer

Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.
 

Domain object does not have any access to any persistence object, remember the term Persistence Ignorance? How do the domain objects make use of persistence object then? Domain object can access the persistence object through repository interface. And the implementation of the repository interface will be handle by Infrastructure layer. What are in the infrastructure layer? There are some repository object, which are implement all repository interface in domain layer.

What kind of method usually reside in the repository object? Based on my experience, I always put the following method in the repository object.

• List<[DomainClass]> list[DomainName]Data,
• List<[DomainClass]> list[DomainName]DataByCriteria,
• [DomaiClass] get[Domain]ById,
• [DomainClass] get[Domain]ByCriteria,
• boolean is[Domain]Exist

Those method stated above will be implemented in the Infrastructure Layer. Hibernate ORM normally is used in the implementation of repository interfaces.

In the Spring application context, modify the xml:

<bean name="repositoryImplementationClass" class="SomeRepositoryImplementationClass">

</bean>

How to use those method in the presentation layer? Spring framework will handle the Dependency Injection. In the presentation class, just add:

DomainNameRepository domainService = null;

and create its getter and setter method.

In the Spring application context xml configuration, modify the file xml code

<bean name="presentationEditor" class="SomePresentationLayerClass">

     <property name="domainService" ref="repositoryImplementationClass"/>

</bean>

Ok, in the previous posting about domain class, we can list all behavior that the domain class can do in the domain class itself. I will take an example of Role Based System. We need several domain class involved: we need the group class, role class, resources classes. Each of those class will contain method that shows the behavior of each domain.

Think of authentication and authorization method, where those methods should reside? In the user domain object? Group domain object? Role domain object? or Resource domain object? None of them. So, any method that is not member of any domain class can be classified in one place as Domain Service.

Authentication and Authorization can not be achieved without using one method in one domain, hence it must be cross domain. Authorization will use user domain’s method and role domain’s method.

As I have mention in the previous posting, DDD object can be modeling into Domain Object and Value Object.

The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar is the same Entity unless it has the same Identity.

Still don’t understand? Ok, think of house, is the house has identity? Off course it has. Is your house my house as well? No way!!! So the house can be treated as Entity class: it has identity, it is not sharable.

Im OK with the entity class concept, but is the value object the same with Value Object in the Java term…

It’s depend!!! In this DDD, the characteristic of Value Object is that it has no Identity. Ok, perhaps a little simplistic, but the intention of a Value Object is to represent something by it’s attributes only. Two VOs may have identical attributes, in which case they are identical. They don’t however have any value other than by virtue of their attributes.

Still blur…

Ok, the example is class paint. Let’s say our entity class want to use the class paint with  color attribute red. Let say, I am using that paint object to paint my house, and the remaining paint i pass to you to paint your house, so in this scenario, paint class is Value Object. It shareable. Let’s put the ID of the class paint, do you think the identification of the paint class is important? We do not need to take care the ownership of the class paint.

One more characteristic of Value Object is immutable, once created they cannot be changed or altered. You can create a new one, and as they have no identity, that is just the same as changing another one.

Ok, what should included in Domain Class anyway? Domain will contain all behavior. Just define any method that the object can do. Take the user domain object: what the user object can do? All getter and setter of all attribute. What else? We will go back to this again later in other post.

references:

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

Persistence Ignoring? You mean we must ignore the storing information in the system? No way!! No, it is not what the DDD means. In DDD, we talk just about the domain. How the behavior of the business object in term of domain. Of course there is still data access activity, but not in domain layer. Domain layer do not care about other layer, domain layer no need to know about how other layer works.

Then how do the object access the database? There is infrastructure layer who responsible to access the database. What kind of class residing in the infrastructure layer? In DDD, we call it Repository class. Repository will provide the access to database via the interface. In the domain layar, the domain object can use the interface to interact with database.

references:

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

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

Ok, assume we got the project to develop the system in SoftONEAlliance Capital Investment Banking. We have a great  Java Enterprise Edition development  team: we have excellent Project Manager, experience System Analyst and ‘geek’ type of System Developer. Don’t forget we have sweet cute Software Testing girl (so if she raise the bug, the guys in development team will not angry to her  )

But, we don’t have domain expert on Investment Banking. Try and find from the client side. We need to have someone who are be able to be our reference in the development phase, person who expert in Investment Banking business process.

Ok, found it as well, now what???

We, the development team need to meet the domain expert. Let us find out all the requirements based on the domain expert explanation. But wait, can they , the domain expert, understand ‘our language’? Does the domain expert understand things like how we understand them? Does the development team have the same understanding like theirs?

Errr…. So?

Yes, we need to use an Ubiquitous Language.

The Ubiquitous Language in DDD is a negotiated language between the Domain Experts and the technical guys – but the rule is that the Domain Experts lead and the technical people follow. As the UL evolves, and this may take weeks or many months, the language becomes more and more refined.

This disjoint is what the concept of the Ubiquitous Language (or UL) is intended to eliminate in Domain Driven Design.

The concept is simple, that development team and the domain expert should share a common language, that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology.

references:

Charlton, C.(2009). Domain Driven Design: Step by Step Guide