Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dominik Guzei
    @DominikGuzei
    Hey @rwatts3, and that's exactly what you should do :-)
    What are you working on currently?
    Ryan Watts
    @rwatts3
    Haha. I'm finishing up a client call on a cold fusion system.
    Dominik Guzei
    @DominikGuzei
    hehe, good old legacy :-D
    Ryan Watts
    @rwatts3
    Yep, sometimes it's bitter sweet
    Dominik Guzei
    @DominikGuzei
    But it is CQRS related?
    Ryan Watts
    @rwatts3
    yes and no
    Rhys Bartels-Waller
    @rhyslbw
    Good to see some new devs in here, welcome!
    Dominik Guzei
    @DominikGuzei
    Continued to work on the space-cqrs example app, fleshed out a basic UI using semantic-ui for showing the products of the shop ;-) https://github.com/SpaceJs/cqrs-shop-example/tree/develop
    you have to symlink the https://github.com/SpaceJs/value-objects into the packages folder atm and make a copy of the environment.example.sh to environment.sh. Then run the app via the ./run.sh shell script.
    it already uses three of the general purpose value objects and only loads those that are configured via the environment.shfile :-)
    Bildschirmfoto 2015-09-06 um 02.24.02.png
    Rhys Bartels-Waller
    @rhyslbw
    Hey Dominik, the new ideas around a repository of components is exciting. I’ve just reviewed space:value-objects, great start. I do wonder though if we are best keeping each one in it’s own package. Seems like we are misusing ENV variables for application reliant configuration?
    Rhys Bartels-Waller
    @rhyslbw
    Pros:
    1. No need to learn a new dev process since we would be using the starndard tools.
    2. Anyone can add Value Objects by writing a new package and realeasing to Atmosphere. We can review and maintain a directory of packages in the Space docs.
    3. Only the code required by the app is pulled into a project.
    Rhys Bartels-Waller
    @rhyslbw
    We could create a style guide for VO and Module packages, and even produce a template repository to show the structure and boilerplate testing code
    rhyslbw:space-vo-foo
    rhyslbw:space-module-orders
    Dominik Guzei
    @DominikGuzei
    Hey Rhys, thanks for the great feedback – you addressed many of the concerns i had in mind while building the repo ;-) Also I realized that often there are groups of value objects that belong together, so we could have mini-packages like space-vo-moneywhich provides Currency and MoneyVOs
    And yeah, a style guide for naming the repos / modules is highly needed
    Timothy
    @timfam
    1+ for style guides and naming convention
    Rhys Bartels-Waller
    @rhyslbw
    Great! Chosing a name for VO collections such as space-vo-monetary instead would be best to communicate the package scope
    Timothy
    @timfam
    Yes
    Dominik Guzei
    @DominikGuzei
    Ok and i also think we should stick to the name "module" for e.g bounded contexts like space-orders-module or space-payments-module what do you think?
    Another thing is that we should centralize the repositories … because atm it's all under the CodeAdventure organization on Github, but space on atmosphere. Are you happy with https://github.com/SpaceJs ?
    Rhys Bartels-Waller
    @rhyslbw
    There is a conflict with http://www.slashie.org/space.js/
    meteor-space ?
    module is good. We can use the DDD terminology within documentation to explain how it can be applied in Space
    Timothy
    @timfam
    Meteor - space works
    I like the bounded context idea for modules. Let's centralized on meteor-space
    Dominik Guzei
    @DominikGuzei
    ok so should we rename the SpaceJs organization on Github to meteor-space?
    I would move the CodeAdventure/meteor-spacerepository to meteor-space/base then (the Meteor package is called space:base, so that would make sense)
    it would also make the repo names nicer because we could omit the spacein the names (e.g: the repos inside the org would then be called base,messaging,ui, cqrs
    Dominik Guzei
    @DominikGuzei
    I created a vo-monetary repo now and rewrote the unit tests for Currency and Money to Javascript too ;-) https://github.com/SpaceJs/vo-monetary
    Dominik Guzei
    @DominikGuzei
    Ok, i renamed the Github org SpaceJs to meteor-spacenow and also created a dedicated Gitter room to discuss the general strategies: https://gitter.im/meteor-space/general ;-)
    Rhys Bartels-Waller
    @rhyslbw
    While on the subject of refactoring… maybe the cqrs module can be renamed to event-sourcing ? I think this is the dominant concept here given most of the infrastructure and components relatate to ES now the messaging has been extracted. Also CQRS is more a style and in itself is mostly down to implementation right. Thoughts?
    Dominik Guzei
    @DominikGuzei
    yeah, i also wasn't really happy with the term CQRS, it has something strange to it ;-) i like the name event-sourcing and will refactor to that when moving the space-cqrs repo!
    Rob Landers
    @withinboredom
    Tell me if I'm crazy, but does anyone see a problem with attaching a snapshot of an object to the stored event?
    Rhys Bartels-Waller
    @rhyslbw
    sorry @withinboredom I had missed this since I had left the room thinking we would be shutting this one down in favour of https://gitter.im/meteor-space/general
    Are you thinking about a snapshotting strategy in general, or are you trying to implement the Space snapshotter?
    Gerald
    @campanagerald
    hi. i have a question. is aggregate id the same as the id of aggregate root?
    thanks in advance