Domain Driven Design Slides

Recap on Lecture 4 - Domain Driven Design

Domain-driven design is focused at the Domain Layer which is one of the common layers in an object-oriented system with a multi layered architecture. Complex domain designs should be based on a model. The domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers. In Domain-driven design, we only need to concern about object oriented concepts. We capture domain elements and represent them in object oriented concepts like objects, methods, etc. The design needs to be both nice and usable as it is the foundation for rest of other stages of software life cycle. When designing, we need to think whether we can implement this design in the real world. We should be able to change the technology, if we couldn’t achieve the design with the existing technology. We should not keep two separate designs for analysis & design phase and for implementation. Design model and the implementation model should be aligned. There should be feed back loop through out the life cycle.

It is needed to avoid mismatches between domain experts and software developers. Multiple words can be used to represent same things and one word can be used to represent the two things. We should avoid those kinds of language ambiguities.

Model Driven Design is broken down into the following artifacts:

• Entities
• Value Objects
• Factories
• Services
• Aggregates
• Repositories

Each one of these artifacts complements one another and allows us to gain greater insight into the business domain. Ubiquitous Language is the backbone or glue rather that holds all these artifacts together.

Services: Services are not part of the domain, but need to carry out the domain. Considering bank domain, transactions can be identified as domain services and providing pawning, and secure safe are some examples for infrastructure service. We can use services to capture responsibilities and system requirements which are not directly related to the domain. Class should have only one responsibility assigned to it.

Modules: In a complex system the model tends to grow bigger and bigger, so it is necessary to organize the model into modules. Therefore modules are used to avoid complexity. Divide and conquer is the method used to handle complexity. Dependencies between modules should be removed. Modules should be able to handle independently. Coupling should be less between modules. These modules also should reflect domain concepts like module naming.

Aggregate: An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. Every aggregate has a boundary. It can be divided into normal aggregates and root aggregates. Root aggregate is the owner of other classes within the boundary. The root holds references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object.

Factories: Objects have a life cycle staring with creation, then retrieving, and ending with deletion. Factories can be used to create complex objects as hierarchies. When a Factory is not needed, we can use simple constructor to create objects. We have to identify correctly when factory is needed. Factories need to create new objects from scratch, or they are required to reconstitute objects which previously existed,

Senarathna P.D.E.(044036)

Comments About Lecture

Domain Driven Design

• The idea of domain driven design is to capture all requirements in our model and can’t assign ad hoc responsibilities to domain classes. This comes with domain layer in layered architecture. Here we don’t concern infrastructure details and technology. We only need to concern about object oriented concepts. That means capture the concepts and represent those concepts in object oriented manner, like classes, objects etc… Normally these are commonly known things. However design should be nice and usable, because it becomes the foundation for rest of other process.


• If the existing design cannot be afforded by using existing technology, it should flexible to change technology to achieve the design. It should not keep two designs for analysis & design and implementation. That should be same. So it can map one to one between design model and implementation model. When it is using only one design there should be a feed back loop through out the life cycle

• Language can use different words to express same thing and can use one word to represent two things. These are wrong. Better way is to represent one word for one thing. Then we can reduce conflicts and provide more meaningful language.
  
  
• Services are not part of the domain, but need to carry out the domain. Actually services capture responsibilities and system requirements. One of the best practice is one class should have only one responsibility. As an example consider the university domain and its parts like library, canteen, bookshop, examination department. All of these are services and library, canteen, bookshop are infrastructure services. So university domain can exist without this domain. But the service like examination department is domain services, means these are mandatory service for university domain. It can’t exist without that domain services.

• We can use modules to reduce complexity. It’s very important to increase cohesion and reduce coupling. It’s important to remove dependencies between modules and provide the ability to work independently. There can be tight coupling within module and reduce the coupling among modules. As an example consider a DVD player and amplifier. Here there are many open jacks to connect other sub systems but no way to change interior of particular sub system. Also these modules should reflect domain concepts.

• Every aggregate has a boundary. It can be divided into normal aggregates and root aggregates. Root aggregate is the owner of other classes. In the example we are discussed customer is the root aggregate. Contact info and address can’t change without knowing the customer. That means customer has full control of these two.

• Object creation and assign something to object is two different things. As an example construct car and use car is two different things. Factories responsible for create objects. If we want to do a particular job we need to call objects. Repositories like directory. Those are help to find objects inside the memory. These repositories hide implementation details, means encapsulation is there. Here we don’t need to concern where the object is and only need to refer matching criteria.

S.R.S. Gunawardana - 044012

Recap of Domain Driven Design with comments by Sir

Domain Driven Design

Domain driven design comes in domain layer in the layered architecture. There we are not concerning about any particular technology or infrastructure, but object oriented concepts. We capture domain elements and represent them in object oriented concepts like objects, methods, etc. The design needs to be both nice and usable. The design which is nice but not usable is not worth and vice versa. When designing, we need to think whether we can implement this design in the real world. We should not keep two separate designs for analysis & design phase and for implementation. It should be the same design we should implement. Although there is a feedback loop through out the life cycle, the same design should continue through out the all stages of the software life cycle.

Language ambiguity:

We should avoid mismatch between domain experts and software developers.

We should also avoid;

• Usage of multiple words to represent the same thing. For example debit & credit and withdraw & deposit to represent the same thing.
• Usage of one word to represent two things.

We should avoid the language ambiguity.

Services:

If we take university domain there we can identify several services which are related to that domain. For example canteen, library, bookshop, examination dept, etc. Canteen, bookshop can be given as examples for infrastructure service and examination, other departments are examples for domain services. We can use services to capture responsibilities and system requirements which are not directly related to the domain. Without services we assign that responsibility to some other class which is not good. Because a class should have only one responsibility assigned to that. We use artificial classes to assign those responsibilities as services.

Modules:

To avoid complexity, we use modules. Divide and conquer is the method used to handle complexity. Since one person can’t comprehend the whole complexity, can use modules. We should remove dependencies between modules, so that they can be handled independently. Within sub system or modules, there exists high level of coupling. But between modules coupling is less. These modules also should reflect domain concepts like module naming, etc.

Aggregates and aggregate roots:

Also known as concurrency control and ownership. Every aggregate has a boundary. If we take a look at the figure above, can’t change contact info or address without knowing the customer. Customer is the owner of it. If two people are going to change this information, there would be concurrency issues. Customer is the one who have the control over the contact info and address.

Object life cycle:

Objects have a life cycle staring with creation, then retrieving, and ending with deletion. Use factories to create complex objects. Otherwise use a constructor. Consider previous figure; if all customers need to have contact information and how we are t enforce this rule? It’s not a customer class responsibility. So create a factory and assign that responsibility.

By: W.A.A.D. Wickramaarachchie [044044]

Domain Driven Design

During the last few lectures on Advance Software Engineering we talked about concepts such as layered architecture, entity objects and value objects etc which all come under the term which was coined by Eric Evans as Domain Driven Design. It is an approach for software design which is based on arguments such as;

1. For most software projects, the primary focus should be on the domain and domain logic. (Not driven by a particular technology)

2. Complex domain designs should be based on a model.(Making understandability high)

For a sophisticated real world software to be well satisfying to its clients, it should be domain driven rather technology driven which ultimately will address the heart of (the sole existence) software. The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose (such as notification and statistical reporting systems etc as added functionality).

How can we make the software fit harmoniously with the domain? The best way to do it is to make software a reflection of the domain. Software needs to incorporate the core concepts and elements of the domain, and to precisely realize the relationships between them. Software has to model the domain. A domain is something of this world, a particular area of discipline or a sphere of knowledge, influence, or activity.

A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail. According to Eric Evans, a domain model is not a particular diagram or a document/specification; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. This can be understandable among all parties involved in the requirement gathering to implementation and so forth.

When choosing a model we can consider the following principles,

• The model is distilled knowledge.

• The model is the backbone of a language used by all team members.

• The model and the heart of the design shape each other.

Ubiquitous has a meaning widespread, constantly encountered; and language has a feature of being vague. It is absolutely necessary to develop a model of the domain by having the software specialists work with the domain experts; however, that approach usually has some initial difficulties due to a fundamental communication barrier. The developers have their minds full of classes, methods, algorithms, patterns, and tend to always make a match between a real life concept and a programming artifact.

The domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers.

A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.

Services

In the ubiquitous language the Nouns are mapped in to objects, and Verbs that are associated with corresponding nouns become the behaviors of those objects. But there are some actions in the domain, some verbs, which do not seem to belong to any object. Adding such behavior to an object would spoil the object, making it stand for functionality which does not belong to it. Perhaps those behaviors can occur in several objects across different classes. Best practice is to declare such behaviors as Services

A service is an operation offered as an interface that stands alone in the model; it provides functionality for the domain. Services tend to be named for what they can do (verbs rather than nouns). A good service has three characteristics

• The operation relates to a domain concept that is not a natural part of an entity or value object
• The operation performed refers to other objects in the domain.
• The operation is stateless (does not maintain or update its own internal state in response to being invoked)

While using Services, is important to keep the domain layer isolated. Because of it is easy to get confused between services which belong to the domain layer, and those belonging to the infrastructure layer. There can also be services in the application layer Domain and application SERVICES collaborate with the infrastructure SERVICES. It can be harder to distinguish application SERVICES from domain SERVICES. Following is the example that describes ho the different services can be divided in to layers.

Partitioning Services into Layers

Application Funds Transfer App Service

– Digests input (such as an XML request).

– Sends message to domain service for fulfillment.

– Listens for confirmation.

– Decides to send notification using infrastructure service.

• Domain Funds Transfer Domain Service

– Interacts with necessary Account and Ledger objects, making appropriate debits and credits.

– Supplies confirmation of result (transfer allowed or not, and so on).

• Infrastructure Send Notification Service

– Sends e-mails, letters, and other communications as directed by the application.

Modules

In a complex system the model tends to grow bigger and bigger. It is necessary to organize the model into modules. Modules are used as a method of organizing related concepts and tasks in order to reduce complexity. They provide two views on a model

· One view provides details within an individual module

· The second view provides information about relationships between modules

Using modules in design is a way to increase cohesion and decrease coupling. It is recommended to group highly related classes into modules to provide maximum cohesion possible. Widely used cohesions

Communicational cohesion: Parts of the module work with same data

Functional cohesion: Parts of the module work together to perform well-defined tasks

Models need to refine until it partitions according to high-level domain concepts and the corresponding code is decoupled as well. Modules and their names should reflect insight into the domain becoming part of the ubiquitous language. After the role of the module is decided, it usually stays unchanged, because module refactoring may be more expensive than a class refactoring

Domain objects go through a set of states during their life time. They are created, placed in memory and used in computations, and they are destroyed. In some cases they are saved in permanent locations, like a database, where they can be retrieved from some time later, or they can be archived. At some point they can be completely erased from the system, including database and the archive storage. Managing the life cycle of a domain object constitutes a challenge in itself, and if it is not done properly, it may have a negative impact on the domain model. Aggregates, Factories and Repositories are three patterns which help us deal with it. Aggregate is a domain pattern used to define object ownership and boundaries. Factories and Repositories are two design patterns which help us deal with object creation and storage.

Aggregates

It is difficult to guarantee the consistency of changes to objects in a model with complex associations such as one-many and many to many associations. Many times invariants apply to closely related objects, not just discrete ones. Yet cautious locking schemes cause multiple users to interfere pointlessly with each other and make a system unusable.

Therefore, we use Aggregates.

An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root Entity has global identity, and is responsible for maintaining the invariants. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. Only Aggregate roots can be obtained directly with database queries. All other objects must be found by traversal of associations. Objects within the Aggregate can hold references to other Aggregate roots. A delete operation must remove everything within the Aggregate boundary at once. When a change to any object within the Aggregate boundary is committed, all invariants of the whole Aggregate must be satisfied.

Nothing outside the Aggregate boundary can hold a reference to anything inside, except to the root entity. The root entity can hand references to the internal entities to other objects, but those objects can use them only transiently, and they may not hold on to the reference. The root may hand a copy of a value object to another object, and it doesn't matter what happens to it, because it's just a value and no longer will have any association with the Aggregate.

How is the Aggregate ensuring data integrity and enforcing the invariants?

Since other objects can hold references only to the root, it means that they cannot directly change the other objects in the aggregate. All they can do is to change the root, or ask the root to perform some actions. And the root will be able to change the other objects, but that is an operation contained inside the aggregate, and it is controllable. If the root is deleted and removed from memory, all the other objects from the aggregate will be deleted too, because there is no other object holding reference to any of them. When any change is done to the root which indirectly affects the other objects in the aggregate, it is simple to enforce the invariants because the root will do that. It is much harder to do so when external objects have direct access to internal ones and change them. Enforcing the invariants in such a circumstance involves putting some logic in external objects to deal with it, which is not desirable.

As an example, the customer is the root of the Aggregate, and all the other objects are internal. If the Address is needed, a copy of it can be passed to external objects.

Address

street city state

customerID name

Customer

homePhoneNumber workPhoneNumber faxNumber emailAddress

ContactInfo

Factories

It is too complex to create in the constructor of the root entity as Entities and Aggregates can often be large and complex. Object creation involves a lot of knowledge about the internal structure of the object, about the relationships between the objects contained, and the rules applied to them. This means that each client of the object will hold specific knowledge about the object built. This breaks encapsulation of the domain objects and of the Aggregates. Therefore we use concept of Factories; Factories are used to encapsulate the knowledge necessary for object creation, and they are especially useful to create Aggregates. When the root of the Aggregate is created, all the objects contained by the Aggregate are created along with it, and all the invariants are enforced. It is important for the creation process to be atomic.

There are several design patterns used to implement Factories. Two patterns among others are: Factory Method, Abstract Factory. A Factory Method is an object method which contains and hides knowledge necessary to create another object. This is very useful when a client wants to create an object which belongs to an Aggregate. The solution is to add a method to the Aggregate root, which takes care of the object creation, enforces all invariants, and returns a reference to that object, or to a copy of it.

There are times when the construction of an object is more complex, or when the creation of an object involves the creation of a series of objects. For example: the creation of an Aggregate. Hiding the internal construction needs of an Aggregate can be done in a separate Factory object which is dedicated to this task.

When creating a Factory, we are forced to violate an object’s encapsulation, which must be done carefully. Whenever something changes in the object that has an impact on construction rules or on some of the invariants, we need to make sure the Factory is updated to support the new condition. Factories are tightly related to the objects they are created. That can be a weakness, but it can also be strength.

Entity Factories and Value Object Factories are different. Values are usually immutable objects, and all the necessary attributes need to be produced at the time of creation. When the object is created, it has to be valid and final. It won’t change. Entities are not immutable. They can be changed later, by setting some of the attributes with the mention that all invariants need to be respected. Another difference comes from the fact that Entities need identity, while Value Objects do not.

There are times when a Factory is not needed, and a simple constructor is enough. Use a constructor when:

• The construction is not complicated.
• The creation of an object does not involve the creation of others, and all the attributes needed are passed via the constructor.
• The client is interested in the implementation, perhaps wants to choose the Strategy used.
• The class is the type. There is no hierarchy involved, so no need to choose between a list of concrete implementations.

Repositories

A constructor or a Factory takes care of object creation. The entire purpose of creating objects is to use them.

In an object-oriented language, one must hold a reference to an object in order to be able to use it. It becomes a problem because one must make sure the client always has a reference to the object needed, or to another which has a reference to the respective object. Such a rule will enforce the objects to hold on a series of references. This increases coupling, creating a series of associations which are not really needed.

Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository

The Repository may store references to some of the objects. When an object is created, it may be saved in the Repository, and retrieved from there to be used later. If the client requested an object from the Repository, and the Repository does not have it, it may get it from the storage. Either way, the Repository acts as a storage place for globally accessible objects.

The Repository may also include a Strategy. It may access one persistence storage or another based on the specified Strategy. It may use different storage locations for different type of objects. The overall effect is that the domain model is decoupled from the need of storing objects or their references, and accessing the underlying persistence infrastructure.

There is a relationship between Factory and Repository. They are both patterns of the model-driven design, and they both help us to manage the life cycle of domain objects. While the Factory is concerned with the creation of objects, the Repository takes care of already existing objects. The Repository may cache objects locally, but most often it needs to retrieve them from a persistent storage. Objects are either created using a constructor or they are passed to a Factory to be constructed. For this reason, the Repository may be seen as a Factory, because it creates objects. It is not a creation from scratch, but a reconstitution of an object which existed. We should not mix a Repository with a Factory. The Factory should create new objects, while the Repository should find already created objects.

Refactoring:

Refactoring is the process of redesigning the code to make it better without changing application behavior. Traditionally, refactoring is described in terms of code transformations with technical motivations. It’s required to look at the code from time to time during the design and development process. Because refactoring may be a requirement. It is usually done in small steps which are controllable. The result is also a series of small improvements to the code. With refactoring we should not break the functionality of the system or should not introduce some bugs. The purpose of refactoring is to make the code better.

Code refactoring can be done in many ways. Even there exist refactoring patterns which represent an automated approach to refactoring. Another type of refactoring which is related to the domain and its model bring some insights to the domain, it gives things clearer, or discover relationship between two elements. Technical refactoring is another type of refactoring. It is also based on patterns & it can be organized and structured.

A solid design resists refactoring, so that the design needs to be flexible. Otherwise whenever a change is needed, you will find it difficult to deal with.

By:

U.W.D.Dilhani (044007)

S.R.S.Gunewardhana (044012)

B.M.Kalupahana (044019)

M.B.P.N.Kumara (044025)

P.D.E.Senarathne (044036)

W.A.A.D.Wickramaarachchie (044044)

Layered Architectue

Charith(044015)

Domain centric means to derive all design from a business architecture perspective.

Domain-driven design (DDD) is an approach to the design of software, based on two premises .For most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system) Complex domain designs should be based on a model.

The term was coined by Eric Evans' book of that title. The book articulates a number of high-level concepts and practices, such as: Ubiquitous language: the domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers. plus a number of specific software design patterns, such as: Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity. Value Objects: An object that has no conceptual identity. These objects describe a characteristic of a thing. Repository: methods for retrieving domain objects should delegate to a specialized 'repository' object such that alternative implementations may be easily interchanged. Factory: methods for creating domain objects should delegate to a specialized 'factory' object such that alternative implementations may be easily interchanged. Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services.

The goal is to construct a technology independent application that retains business objects in original form. To do this an application’s architecture is decomposed

This approach while simple supports long term growth using highly cohesive and loosely coupled software layers that allow change in technology and business processes that would otherwise cause failure in most software structures.

Presentation layer

This is where you find the user interface logic. This logic captures how a user (or other actor) interacts with the application. This interaction includes a common look & feel, and work flow specific to each actor. In addition to each view there may be more than one type of presentation, i.e., (Web, Thick Client, Wireless Application Protocol, etc).

All presentations and views are built on top of the same domain model. Handles presentation layer requests, Defines jobs the software is supposed to do. Coordinates tasks and delegates work to collaboration of domain objects in the next layer down. Can have state that reflect the progress of a task for the user or the program.

Application layer

This layer mediates between the various user interface components on a GUI screen and translates the messages that they understand into messages understood by the objects in the domain model. It is responsible for the flow of the application and controls navigation from window to window. This layer is often partially generated by a window-builder and partially coded by the developer.

Domain Layer

Heart of business software. Technical detail of storing these rules is delegated to infrastructure. Handles application layer requests. A couple of key design goals are

Capture and retaining the business architecture in its purest form. Support for multiple presentations and views without need for specific customization of the domain layer to the needs of any one specific point of view.

When driving software construction from the domain layer the concepts within this layer are reflected outward throughout the other layers in a vertical fashion. Once again reinforcing the idea of driving design from the business architecture.

Persistence Layer

Persistence is where we map data to/from the domain model and long-term storage

By encapsulating persistence in its own layer of functionality it could even be implemented as a remote interface to a distributed system instead of directly talking to an underlying storage device, and from the domain model’s perspective this would be transparent.

Benefits of Layered Architecture

Separating the domain layer from the infrastructure and user interface layers allows a much clearer design of each layer. Isolated layers are much less expensive to maintain, because they tend to evolve at different rates and respond to different needs. This seperation leads to reuse.

1. Modularity, low-coupling – easier maintenance.

2. Business-logic is separated from presentation – reuse.

3. General technical services, e.g., database, are

separated from the business-logic – reused, replaced.

4. Low coupling, separation of concerns – evolving functionality, system scaling-up, adapt to new Technologies

The separation also helps with deployment in distributed system, by allowing different layers to be placed flexibly in different servers or clients, in order to minimize communication overhead and improve performance.

Added by Indika (044051)

Smart UI Anti Pattern

So far we have discussed layered architecture related to domain isolation. Actually it is ideal for software project with more functionalities and more complex domain requirement.

Consider a small project with simple functionalities. If we select domain driven approach the design of the project will became more sophisticated. It may require some time to design the architecture in layer wise But more frequently those projects are given limited time to complete. This type of situation to it is better to choose smart UI anti pattern approach to carryout the project in very simpler and productive way.

What is Smart UI Anti pattern?

Smart UI anti pattern is alternative for layered approach and mutually exclusive from domain isolation. It decouples all the layer functionalities and embedded in to the user interface. So we can’t see any domain isolation here.

Where to apply Smart UI anti pattern?

Case 1:

Suppose Software Company is given a project with simple functionality and it has short time period to finish the project. Still all the domain requirement has not been verified it will take some time to clarify the entire domain requirement. Also there is a possibility of changing business functionality is very high.

Case 2:

Suppose a company has junior staff and they are not experience in domain driven design approach at all. If the management decided to do the project using domain driven approach, it will require considerable time to train the staff. But it is not productive with given time schedule of the project. And also it has some risk as they are doing this type of project in first time. So the possibility of the failure is very high.

Case 3:

There may be situations all the domain requirement has not been clarified and but customer need some modules to be finished with clarified requirements. If we select domain driven approach we have to wait until the domain layer is finished. So it is not possible to release a module of the project with identified requirements. So again smart UI anti pattern approach is ideal to address these types of situations.

Advantages

1. Productivity is high and immediate for simple applications.

It will take less time to finish each module and earn profits.

2. Less capable developers can work this way with little training

3. Even deficiencies in requirement analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit there requests.

4. Applications are decoupled from each other, so that delivery schedule of small modules can be planned relatively accurately. Expanding the system with additional, simple behavior can be very easy.

5. Relational databases work well and provide integration at the data level.

6. When applications are hand off, maintenance programmers will be able to quickly redo portions they cant figure out, because the effect of the changes should be localize to each particular UI.

Disadvantages

1. Integration of applications is difficult to except through the databases

2. There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply.

3. Rapid prototyping and iteration reach a natural limit because the lack of abstraction limit refactoring options.

Layered Architecture

This is the Draft of the Presentation we are going to do on "Layered Architecture".

Entities and Value Objects

by Dasith Gunawardana
Today we are going to discuss about the Entitles and the Value objects. You can find todays presentation in our previous post.

Here is the overview of what we are going to discuss today.

• Domain Driven Design
• Model Driven Design
• Elements of a Model
• Entities
• Value Objects
• Entities Vs Value Objects

So as I start with my presentation, let’s look at what is a Domain Driven Design. Actually Domain Driven Design is an approach to the design of the software based on two premises. In Domain Driven Design the primary focus should be on the domain and the domain logic. The Domain is the area in which the system is going to implement and the domain logic is the process of the system.

In most occasions complex domains are based on a Model because of convenience of understanding the system features.

In a Model Driven Design Analyst responsibility is to capture the fundamental concepts of the domain in a comprehensive manner.

But the designer has to specify set of components that can be constructed with the programming tools to use in the project.

Therefore a Model Driven Design eliminates both issues in Analysis model and design to come up with a single solution which serve both purposes.

Actually a Model Driven Design is software that structures around set of concepts which gives more concern to translate the Model in to code for different technological platforms.

This is the high level view of expansion of the Model Driven Design.

The Model Driven Design comprises of Services, Entities, Value Objects, Layered Architecture and Smart UI which again expand the Entities ad Value objects to Repositories, Aggregates and Factories. But here in our presentation we will be mainly focusing the Entity and Value Objects.

by Eranga Wijebandara - 044046

What is entity?
Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.

This entity object can be easily understand using general example. Take a person he has lot of attributes such as name, color, etc...These attributes are changed during the life time. But even these attributes has changed we can identify that particular person.The reason for that is identity persists.

As same manner object can be identify using it's identity. So during the life cycle of the object the identity will never change.But attributes can be change such as definition,responsibilities , association etc.

Mistaken identity will make lot of problem.

Example:
"A landlady sued me, claiming major damages to her property. The papers I was served described an apartment with holes in the walls, stains on the carpet, and a noxious liquid in the sink that gave off caustic fumes that had made the kitchen wallpaper peel. The court documents named me as the tenant responsible for the damages, identifying me by name and by my then-current address. This was confusing to me, because I had never even visited that ruined place.

After a moment, I realized that it must be a case of mistaken identity. I called the plaintiff and told her this, but she didn't believe me. The former tenant had been eluding her for months. How could I prove that I was not the same person who had cost her so much money? I was the only Eric Evans in the phone book.

Well, the phone book turned out to be my salvation. Because I had been living in the same apartment for two years, I asked her if she still had the previous year's book. After she found it and verified that my listing was the same (right next to my namesake's listing), she realized that I was not the person she wanted to sue, apologized, and promised to drop the case."(Reference:Domain Driven Design by Eric Evans)

So same thing apply to object as well .A case of mistaken identity in a software system lead to data corruption and program error.

by Chathurika Sandarenu - 044034

We now know that the Identity is the most important thing in an Entity. This identity of an Entity can even be applicable outside the application domain. For example we can consider in a Banking application it use account no to uniquely identify accounts. We use this identity; account number to identify an account in general, in our day today lives.

But some identities do not have a meaning when we take it out of that particular application. For example in Operating Systems, it gives unique ID to each process running. If we take that process id alone, without considering the OS it do not have any meaning.

This Identity of an Entity we are talking about is directly depends on the application domain. Depending on application we may choose some objects as entities and same object may not be choosen as an Entity in another application. The idea of Identity does not necessarily have to mach with our real world experience. Things we consider as unique may not consider as unique in some software applications. What is choosen as Entity and their Identity is directly depends on the domain model.

For example if take the object “Seat” in a “Seat Booking” application we have to take it as an Entity since we need to uniquely identify individual seats. But if we consider “General Admission” scenario “Seat” need not to be an Entity. Since in “General Admission” we consider all seats same, we do not need to find out the identity of individual seats.

Litmus test of Entity is the Identity. Doesn’t matter the attribute values are changed in two instances of objects, if those two instances have same identity then they are from same Entity. We can use the same concept with humans, over the time our appearance changes, skin wrinkles, hair color changes, and so many things happen, but still our identity remains same….

Modeling Identity

This is the most important thing regarding Entities. Entities are the most important objects in our domain. When modeling them we have to make sure that they are both lean and powerful. When modeling Entity it is better to keep it as simple as possible. Only put attributes that are necessary to represent the identity. Put anything else into separate objects. Those separate objects can either be Entities or Value Objects. So this way we can have a hierarchy of objects which are attached to one CORE ENTITY. This is also known as aggregate.

Next Important thing, when modeling Entity is what to choose to represent Identity of the Entity. This can be done in many ways depending on the application. One method is to use some attributes or combination of attributes as identity. For example we can use NIC as Identity for Person object, or we may use combination of attributes such as Name and DOB. Another method is to use auto generated IDs. When we use database applications we can use DBMS to auto generate keys and we can use that same key as Identity of our Entity.

by Wajira Somarathne - 044038

Value Objects:

Lets talk about value objects. First think about following 3 circles.

They can be uniquely identified. Because they are colored in 3 different colours. So we can identify each circle by its own colour. Now we will think about this scenario: now think about following 3 circles.

Can you identify each other separately. No .. We can’t. Because each circle is same as others. Lets think we are creating a new shape using this 3 circles like this.

Can you find which circle is on the top, which is at the left and which is at the right? We cannot. And there is no effect whether 1^st circle is on the top or left or right. These kinds of scenarios will be occur in the object modeling also.

We use value objects to address this kind of scenarios by giving more performance to the system. According to the common definition, An object that represents a descriptive aspect of the domain with no conceptual identity is called a value object. Value objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are. That means value objects are not concerning about the identity of each real world things. Value objects are commonly share the attributes of them.

Lets take an example: In software for a mail-order company, an address is needed to confirm the credit card, and to address the parcel. But if a roommate also orders from the same company, it is not important to realize they are in the same location. So Address is a VALUE OBJECT in this case.

By W.G.K.D. Karunarathne - 044022

Consider the Scenario 3.In a software for an electric utility company an address can be considered as an entity object because it corresponds to a destination for the company’s lines and service. If roommates each called to order electrical service, the company would need to realize it. Address is an entity. Alternatively, the model could associate utility service with a "dwelling," an entity with an attribute of address .In this case address can be consider as a value object.

In model driven design approach it is better to use value objects. Even though many programmers think entity objects are better but value object are much powerful than entity objects. We can use value objects in communication to increase the network performance. We can make copies from value objects (not like entity objects) and can send copies of value objects to the client side from server side. On the other hand if we use entity objects need to send objects for client’s each and every request separately. This will caused to increase the server load.

Value objects must be immutable. We cannot change the existing value objects. If we need to change them we need to destroy the object and recreate them. So we can send copies of value objects in communication. As we can use value objects for data transfer we called them as data transfer objects. Value objects can be assembling from other objects. They can be made up of other value objects as well as other entity objects.

Both entity and value objects are principles. We can’t say these are important and these are not important. Entity identity is important and value objects are only for values. But value objects will be more programmatically efficient.

by Anushke L. N. Guneratne - 044014

Odds and ends on Value objects and a Conclusion

As we can see from the posts of others in my group, it is clear that the seperation of entity and value objects is done at the design stage, specially where it is in reference to model driven design.

There are cases when we need to contain some attributes of a domain element. We are not interested in which object it is, but what attributes it has. An object that is used to describe certain aspects of a domain, and which does not have identity, is named Value Object.

Having no identity, Value Objects can be easily created and discarded. Nobody cares about creating an identity, and the garbage collector takes care of the object when is no longer referenced by any other object.

Value objects can be part of a entity object, or it can refernce to entity objects.

Bottom line is in conclusion,
- Value objects are programatically efficient, and are sometimes called Data Tansfer Objects.
- Entity Objects are NOT just an important object, but rather Objects where the Identity is important
- Whilst Value objects are objects where the value is important.

Lecture 1 : Introduction to Software Engineering and associated complexities, OOP overview, grouping and other odds and ends

The first lecture conducted by Mr. Harsha dealt with going back to OOP (Object Oriented Programing) and its fundamentals of design. The deviation of the subject matter from the previous lectures where we were discussing about the need for mathematical basis and about OCL was a surprise.

Several in class activities were conducted in an effort to clarify to the students of the proper need for modeling. It was clear by the end of those that different people would model the same problem in several ways depending on their domain understanding. i.e. they will use the head knowledge to bring about the design. This of course we must understand is detrimental to any proper design, as it will create ambiguities in the documents outlining the design.

If careful observation was made at the end of the day we can see that this lecture looked at the need for a proper design basis (i.e. a mathematical basis perhaps as outlined in an earlier lecture) when it comes to OOP.

The slides used for the presentation highlighted why software was complex, (and also the reason why software engineers are purportedly receiving higher pay) due to.

• Complexity of Problem domain
• Development process management
• Flexibility
• Contradictory requirements
• User/Developer mis-communication

At the end of the day it goes without saying that the vehicle of communication within which we will be learning about Advanced Software Engineering would be OOP. So its fair to expect that during the course of this module we will be seeing aspects of(hmm…)

• Object Oriented Analysis
• Object Oriented Designing

So during the last bit of the lecture there was a re-cap of earlier learned fundamentals present in OOP. These are:

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

The day concluded with groups being made out so that they will be presenting different topics during the rest of the module.

So ended the lecture where over 100 students were in a room designed to hold 64. (no pun or complaint or offense intended)

P.s. we were all asked to blog about the lecture as well as create facebook accounts and groups for the lecture. Hence the blog post. :)

Entities and Value Objects

 

This is the draft of the next Monday's presentation that we are going to do. Even though there will be few modification in the final version, this will be a great help for you all to come prepared...

This is the final version of the presentation, so go through it and come prepared :)

You can also view the full screen version of the presentation through this link.

WHY IMPLEMENTATION INHERITANCE IS BAD.

There are two types of Inheritance.

§ Implementation inheritance: Implementation inheritance allows a super class and a subclass to share identical code for the same method.

§ Interface Inheritance: inheritance wherein one or more classes share a set of messages.

Multiple Inheritance

Both Car and Boat classes inherit from vehicle supper class. Here Car and Boat are child classes.

Diamond Inheritance

Imagine, a smart company builds a vehicle that can be travel on land as well as water called CarBoat (which has properties of Car and Boat)(figure2).

Figure2



W.G.K.D. Karunarathne (044022)
Level4