I'm looking for advice on how to structure namespaces in a CQRS structured application.
Currently the command-side and the query-side are in the same namespace in each bounded context, but as complexity is growing, it is starting to create problems.
Currently the structure has the following folders which each contains the implementation:
Application
+ Api
+ Cli
+ Web
Domain
+ Action (Command and Command Handlers in one - we are not using a CommandBus)
+ Event
+ Model
+-- Project
|-- Project.file
|-- ProjectRepository.file
Infrastructure
+ Consumer (Projections and ProcessManagers)
+ EventStore
+ Persistance (Denormalized read side)
+-- Project
|-- SqlProjectRepository.file
Common (Supporting namespace)
The issue is now that the Domain Model currently contains both the entities and event sourced aggregate root which are essentially only part the query-side and command-side, respectively.
There is no overlap in the aggregates of the query-side and command-side.
In a refactoring to a separation, where should the slice be made?
Suggestion 1
A full slice resulting in a query and a command-side which means that even the Application layer has read and write side.
Suggestion 2
A slice which is only made on the Domain layer so that the query side contains the (quite anemic) entities of the read model and the command-side holds events, event sourced aggregate root and more.
Please make a 3rd suggestion, if mine do not apply. Thanks.
This is the approach I take - based on CQRS and DDD, noting that our DDD extends to having a separate solution (.NET - Web APIs for different domain bounded contexts).
Secondly, all our infrastructure code, auth handling, and shared code - is done in a private package manager, which removes some of the mess, of a single solution, we DI it in the StartUp (DI). Also note we use EntityFramework as our DB implementation.
However, given that, here is how I and my team, separate out CQRS and DDD.
+ App
+- Command
+-- Application.Command
+-- Data.Command.EntityFramework
+-- Domain.Command
+- Query
+-- Application.Query
+-- Data.Query.EntityFramework
+-- Domain.Query
+ Build
+- Pipeline
+ Database
+- Data.Database.EntityFramework
+- Data.Database.Model
+ Test
Api (API app)
Cli
Currently the structure has the following folders which each contains the implementation...
That's unfortunate.
You are likely to be happier with the maintenance burden if you arrange your name spaces such that things that change together are closer together. Your FrobMarbleRepository belongs in the frobmarble namespace, not in the repository namespace.
I don't think I agree with Jimmy Bogard's complete analysis here, but the lesson of focusing on features is important
https://jimmybogard.com/vertical-slice-architecture/
If you happen to need to use the same name for two different ideas within a single feature, then you might end up splitting that feature into two or more namespaces; on the other hand, the need to re-use a name might indicate you are actually dealing with more than one feature.
Related
Due to security reasons, I have to split one project to divisions (client, admin, ...), and deploy them to different web servers. These divisions have one common script base, but each division has its own functions. As an IDE I use PhpStorm.
The question: what is the best way to organize project's structure and settings, so the common core part will be visible for IDE indexing in all project's divisions, but at the same time, being maintained from a single project (perhaps, standalone)?
In Java you can do lib jar files for further linking in various projects.
But how it can be done in PHP?
There are multiple ways of how to reference extra PHP code in a project.
If you plan to actively edit such extra code in the same project (and want to see their TODOs, code inspection warnings, include references in code refactoring etc):
You can just add it as an additional Content Root: Settings/Preferences | Directories. Folder added this way will be treated as a part of the project itself and will be shown as a separate node in the Project View panel (just as the main code, which is a Content Root as well).
Or you can open 2nd project while 1st one is already opened and when asked, just chose "Attach":
It's not going to be full 2 projects in one frame, more like something in between attaching Content Root and having 2 projects opened in separate frames.
https://www.jetbrains.com/help/phpstorm/opening-multiple-projects.html
Simple symlink will also do the job (but you need to place it somewhere in a project, e.g. PROJECT_ROOT/libs/my_symlinked_code). You then will need to provide a path mapping for that folder for debugger (if you will debug it of course) as PHP/Xdebug works with "final/resolved path" while IDE works with the path as is.
If you do not need to actively edit that extra code in the same window (and ignore any TODOs, code inspection warnings and other inspection results etc):
Do it as a composer package then? Composer can use custom sources (e.g. GitHub repo or a folder on a local filesystem).
Just add the path to that folder as a "Include Path" at Settings/Preferences | Languages & Frameworks | PHP --> Include Path tab. Code referenced this way is meant for 3rd party libraries (the code that you just use but not edit, e.g. framework code, your send mail/ORM library etc). Composer packages will also be included here by default.
https://www.jetbrains.com/help/phpstorm/php.html#include-path-tab
I am trying to setup a TDD environment for an app I am building using svelte + sapper.
I need to ignore some files during the compilation (which uses rollup by default)... the reason why I need to exclude them is that I want to have a scalable scaffolding for my application, just like this:
src
|___components
|
|___aComponent
|___aComponent.svelte
|___aComponent.test.js
(e2e tests and integration will probably follow a different structure in order to maintain the separation of concerns and not to bound route and component.
The issue I am having right now is that js files are by default added into the project because of course I may need to create helper classes etc.
I already added exclude: **/*.test.js, but it looks like it's not enough...
here's my configuration.
This came up in a google search for me and is probably old, but in your exclude you have:
{
exclude: ["node_modules/#babel/**", "**/*s.test.js"]
}
instead of:
{
exclude: ["node_modules/#babel/**", "**/*.test.js"]
}
I would like to collect only the depending partials of a single template. Or otherwise ignore unused partials. Because it is a large project with lots of templates/partials and dependencies it is not possible to do that by hand.
Example file and folder structure would be something like:
/sites/foo.hbs - includes {> partial1}
/sites/bar.hbs - includes {> partial2}
/partials/partial1.hbs
/partials/partial2.hbs
Now I would like to precompile foo.hbs only. For precompilation i have to configure foo.hbs as root and /partials/*.hbs as partials.
The precompilation should end up with the content of foo.hbs and partial1.hbs in a single file.
Is that possible with handlebars at all? Maybe with an existing gulp plugin?
Your question contains a (somewhat) logical error.
Partials were initially intended to act as separate templates.
I guess your intentions are basically more syntactic sugar'ish,
- as you wish to write your code separately though merge it on deployment (some people call that OCD, since it has no real benefit in terms of performance).
Anyhow.
You can run a node scripts that runs through your HBS's, locates partials, extracts them into their parent elements and outputs these final templates.
Take a look at this following answer -
find files by extension, *.html under a folder in nodejs
I have an app that has been a standalone app 'til now; however, in another app it's going to be a wee little module.
Is it possible to somehow maintain 1 codebase when the standalone has a source tag of:
<mx:Application>
and the module has a source tag of:
<myModuleBase>
Or is it better to keep a separate branch and just merge them together when the standalone has new changes that I want to propagate to the other?
The standalone app will eventually be taken down as part of phase 2 of this new project but that is several months off and features may be added in the interim.
Can I do this with a separate application file?
Thanks for any helpful tips!
This shouldn't be too difficult to implement. (Disclaimer: I have not messed with modules in Flex)
You have two top-level files, appNameStandalone.mxml and appNameModular.mxml
Those only include the main mx:Application and MyModuleBase tags, and contain inside them an MXML component that represents the actual application.
//appNameStandalone.mxml
<mx:Application ...properties>
<myComponents:UIAndFunctionalityComponent/>
</mx:Application>
//appNameModular.mxml
<MyModuleBase ...properties>
<myComponents:UIAndFunctionalityComponent/>
</mx:MyModuleBase>
If you're not certain how to do this in practice (say, in Flash Builder), you can work under one project directory with two Flex Applications (Project -> Properties -> Flex Applications) or have two separate projects containing only the top-level MXML file with the source folders containing the remainder of the application in the build path (Project -> Properties -> Flex Build Path -> Source Path).
If I've got some misunderstanding as to how the modular version works, please let me know and I'll attempt to correct my answer.
I need to override a function in this file:
app/code/core/Mage/Core/functions.php
The problem is that this is so core that there’s no class associated to it, probably because Core isn’t even a module. Does anybody know how to override a function in the file without a class?
Any help would be appreciated.
Copying the file to app/code/local/Mage/Core/functions.php should not be used because of the following reasons:
The entire file has to be copied over making it harder for us to identify what changes have been made.
Future upgrades could introduce new features that would not be available unless it is remembered to copy across the new version of that file and implement the changes again.
Future upgrades could address bugs with core that we would miss unless it is remembered to copy across the new version of that file and implement the changes again.
In respect to points 2 & 3 each upgrade could change the way things work that means revisiting what changes we need to make. In some cases this will be true for overriden methods as well but at least we can easily identify where those changes effect us.
What do you do if another person wants to use the same technique? Being able to identify what is core code and what is ours becomes more and more complex.
Keeping our code together as a “module” becomes more difficult as by copying in the core file means that we have effectively locked it into being “guaranteed” to run on the version of the software that we have copied the original code from. It also means reusing this work is a lot more difficult to do.
Identifying why the code was changed it much harder as it is outside our namespacing, ie all development related to “Example_Module” is in the namespace:
/app/code/core/local/Example/Module
whereas code copied to app/code/core/local/Mage only indicates that we have made a change to support an unknown feature etc.
Also Magento occasionally release patches which fixes bugs – these will only patch files inside core leaving your copied file without the patch.
What I would suggest instead is that you write your own function to do what you want and override the function to call your new function instead.
Maybe I did not understood your question right but why not just copy this file into
app/code/**local**/Mage/Core/functions.php
and modify it there in any way you want?
As mentioned by #tweakmag the disadvantages of creating a folder structure and copying the entire Model or controller for a single function override, most important being,
"Future upgrades could introduce new features that would not be
available unless it is remembered to copy across the new version of
that file and implement the changes again."
Thus a solution can be, to extend the core class (Model or controller) and just write the method you want to override, instead of copying all the methods.
For example, if you want to say, override a method getProductCollection in Mage_Catalog_Model_Category, here will be the steps:
Create a Custom Namespace/Module folder with etc folder in it
Register the module in app/etc folder by creating Namespace_Module.xml
setup the config.xml in Namespace/Module/etc/ :
<?xml version="1.0"?>
<config>
<modules>
<Namespace_Module>
<version>1.0</version>
</Namespace_Module>
</modules>
<global>
<models>
<catalog>
<rewrite>
<category>Namespace_Module_Model_Category</category>
</rewrite>
</catalog>
</models>
</global>
</config>
create Model folder in Namespace_Module and a Php File Category.php
Now the main difference here is we extend the Magento's core class instead of writing all the methods
<?php
/**
* Catalog category model
*/
class Namespace_Module_Model_Category extends Mage_Catalog_Model_Category
{
public function getProductCollection()
{
// Include your custom code here!
$collection = Mage::getResourceModel('catalog/product_collection')
->setStoreId($this->getStoreId())
->addCategoryFilter($this);
return $collection;
}
}
The getProductCollection method is overridden so it'll be called instead of the method defined in the core model class.
Also an important point is:
When you override any methods in models, you should make sure that the data type of the return value of that method matches with the data type of the base class method. Since model methods are called from several core modules, we should make sure that it doesn't break other features!
This link gives a step by step approach to it
1. UOPZ
There's a way to do it without having to copy and maintain functions.php file from core, but it involves extension uopz (pecl install uopz), then you can rename magento's function (from foo to foo_uopzOLD for example) and define your own (https://secure.php.net/uopz)
It works and is very useful for magento - usually you'll bump into something you can not change. Uopz is very helpful in such cases.
pros: works ;), you don't have to redo it everytime you update Magento (if you do it right, because inside you still can call foo_uopzOLD so you can assure some backward compatibility... in some cases).
cons: it's little bit implicit
2. Composer post-install-cmd
If you don't like the above, but you use composer you can patch any file you want:
"scripts": {
"post-install-cmd": "patch -p0 < change-core-functions.patch"
}
pros: explicit (when patch fail - composer install fails), and since it's explicit - you can revisit and fix the patch every time you upgrade magento
cons: you have modified core file, so you probably would want to add it to .gitignore
3. Ugly solution (uglier than those above)
If none of the above is possible for you (really, give it a try with composer - there's no excuse for not using it). But when you really can not the only way I can think of
- create app/local/Mage/Core/functions.php
- define this one function you need
- load original /app/core/Mage/Core/functions.php
- surround every function foo() {...} with
if(!function_exists("foo"){
function foo() {...}
}
hold on to your chair and
eval this SOB ;)