mattia-battiston / clean-architecture-example Goto Github PK

change
reconcileBroadbandAccessDevicesUseCas

to

reconcileBroadbandAccessDevicesUseCase

Hi @mattia-battiston,

I hope you are doing well.
I have one question. How would you create deployable war (to standalone Tomcat) from this project on the root level?
There is an option to create a war from the configuration module, but that isn't so appropriate.
Do you have some script for that or to play around by myself a little bit with that? :)

Thanks.

Ivan

Your use case should take two inputs and return nothing. The first input is whatever data is necessary to do its job. This is not a domain layer entity. It's a DTO. The second is an interface for a presenter. This presenter takes a response DTO, not an entity. The use case calls the presenter when it feels like it.

https://softwareengineering.stackexchange.com/questions/357052/clean-architecture-use-case-containing-the-presenter-or-returning-data

Hello,

What if I create a new use case, like getSomething, and use the same DoesExchangeExist class.
Should I use this class or create new class for new use case?
Thanks in advance!

Best regards,
Huka

Unit Tests:
for TDD (a.k.a. Tests first, to drive design)
Cover every little detail, aim for 100% coverage
“Dev to dev” documentation: What should this class do?
Test individual classes in isolation, very fast

Cover every little detail and tend to cover 100% with unit tests will give us a hell of re-working every piece of test each time logic is changed))

Should it be "domain" or "use case"?
I can see reasons for both answers.

Any thoughts about it?

Shouldn't there be an arrow from the configuration layer to the data provider layers?

How do we configure data providers like db, network parameters, etc.?

Hi,

In his book uncle bob writes that entities should not be passed to use cases or returned from use cases, which is clearly not the case in this repo.

I was wondering if that is intentional, and if so, why?

From what I understand, A use case input and output should be a DTO, thus preventing upper layers from ever having access to an object two layers down.

Which layer should the transaction management be on?

I noticed your models/entities do not cary ID generated by DB. It does makes sense to me that we don't want to expose this as different data providers may handle record IDs differently. I'm thinking about the best way to handle case of User entity where somewhere on the outside request comes in to update information of a User. Email address could be used in such case or perhaps UUID. Thoughts?