Discussion of Lagom project development: https://github.com/lagom/.github/blob/master/CONTRIBUTING.md | Use lagom/lagom channel for general discussion. | Code of Conduct: https://www.lightbend.com/conduct | Forums: https://discuss.lagomframework.com | Commercial support from https://www.lightbend.com/
:point_up: August 20, 2018 3:55 PM LOL
:smile:
Let me clone on my work laptop and give it a shot
And not to replace it with
% "compile->compile;test->test"
I think that should work.
It seems OK now... I'll commit it.
I guess just with a
@Before and @After
I almost wonder if the resetting of the issues buffer is worthy of being considered a bug?
i.e.,
allIssues doesn't actually capture all issues of a driver -- it captures all issues of a run
It’s worth discussing on the original issue lagom/lagom#1348 though to get more feedback.
Oh, I see..
My team has been really fond of something like this:
api
├── MyService.scala
├── domain
│ └── package.scala
├── events
│ └── package.scala
└── commands
└── package.scalawhich is really organizationally nice... not sure if that's how opinionated Lagom wants to be, though.
Similar thing for impl, but we have readsides, entities, etc.
that way the domain, api, and impl (infrastructure) are separated according to the hexagonal architecture
Does it make sense to prescribe/recommend a repo structure?
I have to write a blog post about that
To enforce some rules, we’ve “improved” (for us, at least) the Lagom layout
there’s more than
api and impl for each services
then you can enforce that some code are isolated from each other
and maybe more. I forgot. I don’t work that much on that project these days
api depends on dto and messages but dto and messages don’t know each others