Some important terms in Clean Architecture.

Clean Architecture is a hot topic nowadays, but i still see lots of my friend, they’re still very confused about some terms like Enterprise business rules, domain logic, application logic, entities… So i want to write this for anyone who still confused like my friend, hope it can help you. Of course i can not explain all of these, but i tried my best to sum of the most popular terms (actually only 10, not much 😔, but if you like it, tell me, i will write part 2 😊). And if you still have something that confused you, tell me in the comment below, I will try my best to answered your question.

Now, enjoy ! Hope you will like it ❤️

1. Enterprise business rules:

This is your business policy in real world. Let’s imagine you want to start your startup (your business) it is FoodDelivery, then you think in your mind it will have some features like:

• Apply discount for any user who is poor (1).
• Reward shipper if they work hard enough (2).

So these ideas (If they come true) it will be your Enterprise business rules.

VERY USEFUL EXAMPLE ☺️: Remember that it doesn’t depend on any framework that you are going to use, It exists because your startup (your business) exists not because Android, or IOS or anything else. If you start your business on both Android and IOS, then they share the same Enterprise business rules. And if you copy other startups ideas then maybe you copy some of their Enterprise business rules (just for fun hope it will help you understand it better 😗).

2. Enterprise business logic:

This is the implementations of Enterprise business rules, Enterprise business rules but in more detail.

Example:

(1): Its implementation would be: Discount 50% the shipping fee for any user who has income <= 500$/month.

• It don’t care about how to get the users income because this is the business of your application (use case).

(2): Its implementation would be: Reward 25$ for any shipper who work more than 6h/day.

• One more time, Business logic doesn’t care about how to get shipper’s working hours, at this level you don’t care about these “small” things.

3. Entity:

This is your business objects, they are least likely to change when something external changes (it isn’t changed because your UI is changed). And it is POJO class (very important). And your business logics around that business object is its class-method.

ShipperEntity doesn’t know about anything, it don’t know how to get its properties, reward-method just use the ShipperEntity’s properties to calculate. POJO can help you understand it better, search for it on the Internet to learn more.

Here is some properties of POJO as well as Entity:

1. All properties must be public setter and getter.

2. All instance variables should be private.

3. Should not extend pre-specified classes.

4. Should not Implement pre-specified interfaces.

5. Should not contain pre-specified annotations.

6. Could have no-argument constructor.

7. Does not requiring any class path (important).

4. Application business rules:

This is the features of your app, the TODO-List that your app need to get “done” to be your app, it’s like Enterprise business rules but it is specific for your application.

For example in our FoodDelivery Android app we can have some feature like:

• Get the user by email.
• Login with Google/Facebook/Email (in IOS maybe we could have login with Apple ID, but it is application business rules of your IOS app)
• Get some hot foods.
• Order food.
• Pay by credit card (in IOS we could have pay by Apple Pay).

These feature is some of your Application business rules in your Android App.

5. Application business logic / Use case / Interactor:

This is the logics behind your app features (application business rules). The implementation of your Application business rules

This is what Martin Robert write in his book — Clean Architecture:

The software in the use cases layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. This use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to archieve the goals of the use case.

Examples:

• Your application business rule is Get the user by Email so it’s logic would be:

A use case should only have one public method.

6. Port:

It is used for dependency inversion, because nothing in the inner circle can know about the outer circle. So your ports will stay in the same layer with your use case.

• Output port: Your Presentation (Controller/Presenter/ViewModel) will implement it, so that use case can interact with your UI easily without knowing it.
• Input port: It has the same purpose as the Output port, but for the data layer. It is Responsitory interface.

7. Domain logic:

It includes your

1. Enterprise business rules
2. Enterprise business logics
3. Entities.

8. Application logic:

It includes your

1. Application business rules
2. Application business logics/usecases/interactors
3. Ports.

9. Domain layer:

This layer contains your Domain logic.

10. Application layer:

This layer contains your Application logic.

But why in most of projects we’ve seen before we only see the domain layer, that because they put Domain logics and Application logics stay in the same layer (Domain package) because maybe their Application logic is small, so they group them together.

Actually this is my first story on Medium ❤️, and i’m not come from English speaking country, If anything goes wrong, please let me know in the comments below, i really appreciate that.

If you still have something that confused you, tell me in the comment, I will try my best to answered your question ❤️

If you like it, don’t forget to give me some claps 🙌👐👏❤️