Plugins as Modules from David Dawson Talk

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Plugins as Modules from David Dawson Talk

Gregg Bolinger-8
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg
Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

sergiomichels
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg

Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Roberto Guerra
In reply to this post by Gregg Bolinger-8
I was thinking of the same thing. Was thinking that maybe in a case like this, the shared-models would be a plugin by themselves. 


On Mon, Jul 22, 2013 at 3:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg



--
Color me impractical but I’d rather be able to look at myself in the mirror than be rich.
-Evan Light
Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Gregg Bolinger-8
In reply to this post by sergiomichels
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.

On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg


Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

sergiomichels
24 mins he talks about "one way dependency" that I think that's exactly this case. Many of your modules will depend on the User module, but don't make the user module depend on others.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg



Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Gregg Bolinger-8
Right, but then at 25:35 he talks about breaking the dependency completely. :o)  I wish he would have talked about Domain relationships with regards to modularity.  There are conflicting concepts.

On Mon, Jul 22, 2013 at 4:52 PM, Sergio Michels <[hidden email]> wrote:
24 mins he talks about "one way dependency" that I think that's exactly this case. Many of your modules will depend on the User module, but don't make the user module depend on others.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg




Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Roberto Guerra
In reply to this post by Gregg Bolinger-8
Yeah, I think that the 'models' would be sort of a 'technical plugin'. Probably the concept of Hexagonal Architecture wasn't well explained in the talk. In an architecture like that, the persistence layer is just an adapter, and is not tightly coupled to the domain logic. What you were referring to in your question was more persistence related. You can abstract that out entirely using Abstract classes and have a grails domain class that deals with persistence only.
For example, lets say you have a Student class that you use throughout all your applications. It is used in a swing app, a grails app and maybe an android app. This can be located in a project/module/jar of its own:

abstract class Student {
    String fullName
    Date dateOfBirth
}

And maybe you also have an implementation of Student in your core module:
class HigherEdStudent extends Student{
}

You can create a grails plugin that deals only with persistence:

class HigherEdStudentGorm extends Student{
}


And wrap all persistence related transactions in a service:

Student save(Student student){
    HigherEdStudentGorm _student = (HigherEdStudentGorm) student
    _student.save()
}

This way, you can develop your core logic independent of the framework and just wire them together with 'adapters'. Much like what Hexagonal Architecture advocates for. The only thing you would use grails for is as a delivery mechanism, and in this case, as a persistence adapter. It also makes it easier to try out other frameworks, since most of the business logic lives in an 'independent' module. With something like this, dependencies tend to flow in one direction only, towards your core logic. 


On Mon, Jul 22, 2013 at 3:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg





--
Color me impractical but I’d rather be able to look at myself in the mirror than be rich.
-Evan Light
Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Sebastian Gozin
Always like to see explanations like this from you Roberto.
This is exactly how it's done.

PS: I've noticed in my own projects that I can't get excited for really declaring data models explicitly anymore so I just use them dynamically which removes the need to create a separate jar module if it's only going to declare structs. Groovy can already use objects and hash maps interchangeably when it comes to struct like datastructures so might as well use those.


On 23 Jul 2013, at 00:05, Roberto Guerra <[hidden email]> wrote:

Yeah, I think that the 'models' would be sort of a 'technical plugin'. Probably the concept of Hexagonal Architecture wasn't well explained in the talk. In an architecture like that, the persistence layer is just an adapter, and is not tightly coupled to the domain logic. What you were referring to in your question was more persistence related. You can abstract that out entirely using Abstract classes and have a grails domain class that deals with persistence only.
For example, lets say you have a Student class that you use throughout all your applications. It is used in a swing app, a grails app and maybe an android app. This can be located in a project/module/jar of its own:

abstract class Student {
    String fullName
    Date dateOfBirth
}

And maybe you also have an implementation of Student in your core module:
class HigherEdStudent extends Student{
}

You can create a grails plugin that deals only with persistence:

class HigherEdStudentGorm extends Student{
}


And wrap all persistence related transactions in a service:

Student save(Student student){
    HigherEdStudentGorm _student = (HigherEdStudentGorm) student
    _student.save()
}

This way, you can develop your core logic independent of the framework and just wire them together with 'adapters'. Much like what Hexagonal Architecture advocates for. The only thing you would use grails for is as a delivery mechanism, and in this case, as a persistence adapter. It also makes it easier to try out other frameworks, since most of the business logic lives in an 'independent' module. With something like this, dependencies tend to flow in one direction only, towards your core logic. 


On Mon, Jul 22, 2013 at 3:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg





--
Color me impractical but I’d rather be able to look at myself in the mirror than be rich.
-Evan Light

Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Marcin Gryszko-2
It's a nice approach. I didn't think about extending a domain class (I mean _true_ domain class, some kind of aggregate/enitty in DDD terms) and mapping it through GORM.

How about relationships? If you relate two domain classes by their_business_ id, no issue - your repository (implemented as service in Roberto's example) resolves references to instances.

But if your classes have a _direct_ object reference (e.g. between an aggretate and an entity, say Order-OrderItem)? Is this mappeable through GORM as in Roberto's approach?

Marcin Gryszko      


On Tue, Jul 23, 2013 at 1:34 AM, Sebastian Gozin <[hidden email]> wrote:
Always like to see explanations like this from you Roberto.
This is exactly how it's done.

PS: I've noticed in my own projects that I can't get excited for really declaring data models explicitly anymore so I just use them dynamically which removes the need to create a separate jar module if it's only going to declare structs. Groovy can already use objects and hash maps interchangeably when it comes to struct like datastructures so might as well use those.


On 23 Jul 2013, at 00:05, Roberto Guerra <[hidden email]> wrote:

Yeah, I think that the 'models' would be sort of a 'technical plugin'. Probably the concept of Hexagonal Architecture wasn't well explained in the talk. In an architecture like that, the persistence layer is just an adapter, and is not tightly coupled to the domain logic. What you were referring to in your question was more persistence related. You can abstract that out entirely using Abstract classes and have a grails domain class that deals with persistence only.
For example, lets say you have a Student class that you use throughout all your applications. It is used in a swing app, a grails app and maybe an android app. This can be located in a project/module/jar of its own:

abstract class Student {
    String fullName
    Date dateOfBirth
}

And maybe you also have an implementation of Student in your core module:
class HigherEdStudent extends Student{
}

You can create a grails plugin that deals only with persistence:

class HigherEdStudentGorm extends Student{
}


And wrap all persistence related transactions in a service:

Student save(Student student){
    HigherEdStudentGorm _student = (HigherEdStudentGorm) student
    _student.save()
}

This way, you can develop your core logic independent of the framework and just wire them together with 'adapters'. Much like what Hexagonal Architecture advocates for. The only thing you would use grails for is as a delivery mechanism, and in this case, as a persistence adapter. It also makes it easier to try out other frameworks, since most of the business logic lives in an 'independent' module. With something like this, dependencies tend to flow in one direction only, towards your core logic. 


On Mon, Jul 22, 2013 at 3:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg





--
Color me impractical but I’d rather be able to look at myself in the mirror than be rich.
-Evan Light


Reply | Threaded
Open this post in threaded view
|

Re: Plugins as Modules from David Dawson Talk

Gregg Bolinger-8
This is great information but I still feel like there is a missing piece between what the presentation covered and the data layer.  Roberto's last response was great but I feel like he took it to the next level.  There still seems to be a gap.  I'll keep digging.


On Tue, Jul 23, 2013 at 6:38 AM, Marcin Gryszko <[hidden email]> wrote:
It's a nice approach. I didn't think about extending a domain class (I mean _true_ domain class, some kind of aggregate/enitty in DDD terms) and mapping it through GORM.

How about relationships? If you relate two domain classes by their_business_ id, no issue - your repository (implemented as service in Roberto's example) resolves references to instances.

But if your classes have a _direct_ object reference (e.g. between an aggretate and an entity, say Order-OrderItem)? Is this mappeable through GORM as in Roberto's approach?

Marcin Gryszko      


On Tue, Jul 23, 2013 at 1:34 AM, Sebastian Gozin <[hidden email]> wrote:
Always like to see explanations like this from you Roberto.
This is exactly how it's done.

PS: I've noticed in my own projects that I can't get excited for really declaring data models explicitly anymore so I just use them dynamically which removes the need to create a separate jar module if it's only going to declare structs. Groovy can already use objects and hash maps interchangeably when it comes to struct like datastructures so might as well use those.


On 23 Jul 2013, at 00:05, Roberto Guerra <[hidden email]> wrote:

Yeah, I think that the 'models' would be sort of a 'technical plugin'. Probably the concept of Hexagonal Architecture wasn't well explained in the talk. In an architecture like that, the persistence layer is just an adapter, and is not tightly coupled to the domain logic. What you were referring to in your question was more persistence related. You can abstract that out entirely using Abstract classes and have a grails domain class that deals with persistence only.
For example, lets say you have a Student class that you use throughout all your applications. It is used in a swing app, a grails app and maybe an android app. This can be located in a project/module/jar of its own:

abstract class Student {
    String fullName
    Date dateOfBirth
}

And maybe you also have an implementation of Student in your core module:
class HigherEdStudent extends Student{
}

You can create a grails plugin that deals only with persistence:

class HigherEdStudentGorm extends Student{
}


And wrap all persistence related transactions in a service:

Student save(Student student){
    HigherEdStudentGorm _student = (HigherEdStudentGorm) student
    _student.save()
}

This way, you can develop your core logic independent of the framework and just wire them together with 'adapters'. Much like what Hexagonal Architecture advocates for. The only thing you would use grails for is as a delivery mechanism, and in this case, as a persistence adapter. It also makes it easier to try out other frameworks, since most of the business logic lives in an 'independent' module. With something like this, dependencies tend to flow in one direction only, towards your core logic. 


On Mon, Jul 22, 2013 at 3:40 PM, Gregg Bolinger <[hidden email]> wrote:
Hm, that makes sense, but not in the context of David's talk in that he was pretty anti-coupling of modules. Which is what this would create.  As well as a possible circular reference.  I love theoretical talks but it would have been nice to see even a simple example of the recommendations.

The way David described this is that each module would talk to each other over (Enterprise) Integration Points.  I realize that his ideas were probably ideal, perfect world, examples.  But I'd be interested in more practical information on the application of the theory.

Maybe the vertical slices aren't broken up where entities have to be related to each other, as Roberto (I think) was suggesting.  And the modules were more stand alone chunks of business logic like sending emails or processing invoices, etc.


On Mon, Jul 22, 2013 at 4:27 PM, Sergio Michels <[hidden email]> wrote:
In this case, your Order module depends on User module, so you will add this in the plugins of Order and will be able to reference the User module classes.

--
Sérgio Michels


On Mon, Jul 22, 2013 at 6:07 PM, Gregg Bolinger <[hidden email]> wrote:
I just finished watching the following:


It was a great presentation but it left me with one main area of confusion.  Let's say you're breaking your application into vertical slices.  How do you deal with domain relationships between the modules?  For example, assume there was a module to manage the biz logic around users and another module to manage biz logic around orders.

In this scenario, there are relationships between users and orders.  However, if I understood the presentation correctly, User and Order are in 2 different vertically sliced modules.  What is the solution for this?  Or what am I missing from the presentation?

Thanks

Gregg





--
Color me impractical but I’d rather be able to look at myself in the mirror than be rich.
-Evan Light