I have been working with MVC frameworks (PHP) for a while now, and I believe I understand the notion of layers separation pretty well.
For whoever is not there yet I'm talking about:
M => Model, data layer;
V => View, the UI of the application;
C => Controller, where business logic and incoming requests are processed;
Recently I came across a few projects that extend this concept by using other layers and extending the model one.
These layers use classes such as services, repositories, transformers, value objects, data mappers, etc.
I also understand the essential idea of DDD but, I'd like to know what this type of architecture mentioned above is called, if these additional layers are connected with DDD and/or any design patterns and if you guys can share some resources (blog post, books, videos, etc) where to learn this stuff from whit the other users of this community.
for reference, I found tereško's aswer on this question which is something very similar to what I am looking for.
Many thanks
These layers use classes such as services, repositories, transformers,
value objects, data mappers, etc.
It's hard to ascribe those to any specific architecture. For example Value objects are aka Data Transfer Objects (DTOs), aka Plain Old CLR/Java Objects (POCO/POJO's) are commonly found in .Net / Java based OO solutions.
More fundamentally, as you might already know, logical Layers ('...are merely a way of organizing your code.'*) are a fundamental concept in software architecture, so you'll find them all over the place, and not specific to any one architecture.
See Panos's in-depth answer for 'What's the difference between “Layers” and “Tiers”?'.
share some resources (blog post, books, videos, etc)
In terms of architectures, architectural styles that use layers, and into which the concepts you list would fit:
5-Layer Architecture (one I documented in 2011, which I still use)
Ports & Adaptors aka Hexagonal Architecture There seems to be a lot about Hexagonal architecture around at the moment, of which this post is the best I have seen.
A lot of the key concepts in both of these are actually very similar.
The general ideas behind both of these are very similar. You'll find other architectures out there, I'm sure, but how much they substantively differ is another question.
I'll make this a community wiki so others can add any resources they know of.
Related
CakePHP Applications being made in our company tends to become unmaintainable as it becomes more complex. I figured that one specific reason is inheritance which makes the functions in child classes depends a lot on it's parent classes and vice-versa (implementing template method pattern). Why is CakePHP designed this way and not friendly in using Dependency Injection, Strategies, or Factory patterns?
There is not such a bad design as you claim in the framework. Sure, there are probably things that could be done better but I would like to see a more substantial critic including solid arguments and examples. I assume you're not using the framework as it was intended.
Let me quote the first paragraph from this page.
According to Eric Evans, Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture. The domain model provides a structural view of the system. Most of the time, applications don’t change, what changes is the domain. MVC, however, doesn’t really tell you how your model should be structured. That’s why some frameworks don’t force you to use a specific model structure, instead, they let your model evolve as your knowledge and expertise grows.
You're not showing code (for a reason?) so I guess your problem comes from stuffing everything into the table objects in src/Model/Table/ or doing something similar.
But you're totally free to create a folder structure like
/src/Service
/src/Model/Domain
and then simply instantiate services as you need them in your controller actions. A service could be for example \App\Service\User\Registration and using objects from App\Model\Domain\User.
I agree that the framework in fact doesn't provide any recommendation or template structure for how this could look like. For exactly this topic there is a discussion going on here. Because of a lack of such a structure I've started working on a plugin that provides this. The plugin doesn't require but suggest the usage of DI containers for the people who want them.
Given the whole fancy topic around DI and DDD so far I would say there is not the one way to get things right but different paths as long as the code is easy to maintain. And honestly, as long as this goal is archived I really don't care about how you call it. :) I think many people tend do make this topic to academic instead of simply trying to be practical.
Not everybody is even needing that structure. It depends on if you're building a RAD CRUD application or a more complex app. Not every application needs a DDD approach. There are so many shades of gray when it comes to design the business layer, no matter how the framework would do it, somebody would always complain about it.
I personally almost never missed a DI container in CakePHP, not even in the biggest project having more than ~560 database tables which was a hospital management solution and it just worked well.
I would suggest you to ask a more specific question about your approach how you structured your code and showing your structure and code and then asking for advice on how to improve it instead of blaming the tool you're using in the first place without providing context.
Unfortunately CakePHP v3 can not compare to the Zend3/Laminas, Symfony or Laravel.It is 7-8 years behind the other frameworks.If you are using cake for years or it is your 1st and last framework it is normal to not realise that.But if you have to use it after Zend 3... cake seems like really bad ecosystem.
Bad documentation
Bad ORM
Poor Routing system
Bad Templating engine
Bad idea to mix Data Mapper and Active Record
DIC is totally missing
Components - not good but not terrible
...
And many more thinks that should not be underestimated like - lack of GOOD tutorials, pluigns/addons/packages
The above thinks make developers to follow bad practices that adds a lot of technical depth.
If you care just for - it works! But not how it works and why it is bad, cake will fit ok for you.
Cake can not scale as good as Symfony/Laminas if you are doing big project.(yea AWS/GC can help for scaling a lot of thinks but not for scaling source code)
Cake doesn't allow you rapid development like Laravel/Symfony for decent project.
I'm wondering who and WHY would start a new project today using Cake as it has zero benefits over the other frameworks.
Probably only devs who used only Cake for last decade and do not want to start learning new technologies or devs that thinks SOLID is just a fancy hype with zero benefits like design patterns, DRY and KISS
CakePHP framework supplies user interaction with databases using Active record, it means that exist a high coupling between business layer and database layer which has negative effects in unit testing and because of that the framework is not friendly with Dependency Injection. The same issue happens with Factory pattern, high coupling mentioned before makes more difficult use simulated objects in unit testing.
Hope it helps!
Alberto
I am beginning in UML and software analyse and i do not understand how UML and diagrams can influence coding and software architecture while we can directly build the code and its data base without diagrams.
I read lot of tutorials abouat the subject but not enough to understand the utility of UML in coding.
I understand everey diagram and its role. That is not my problem but i do not yet understand their roles after the analyse and design phase.
So what is the role of UML in coding phase of a software ?
Thank you.
The comment by #xmojmr already puts it right. UML creates a model (hence the M in UML) of a system. A model reduces information of a system to a level so it is a) manageable and b) complete. Human brains are not computers and you need a means of communication what the system is all about. You can do that as pure code, as paper document and as UML model. A combination of all is not uncommon. As long as you have tiny systems you can live with pur code and tools like Doxygen. But once it starts getting complex you need some handles. UML offers these to end users, architects, testers, developers, managers, etc. Along with UML you will also need a methodology. UML delivers the syntax how to document a system. But you need some structure above to write a nice novel.
UML-based models play an essential role for coding/implementing a software system in model-based (or model-driven) development. The basic idea is that you start making a model of your problem domain (the domain model), then you derive from it a platform-independent design model, which can be transformed into platform-specific implementation models (e.g. for Java- or C#-based platforms) that are finally encoded in the target languages.
The most prominent part of model-based development is the encoding of model classes (forming the model layer in an MVC architecture for apps) based on a data model (a UML class model) that has been derived from an information design model, which was obtained from a domain information model (where all these information/data models are UML class models).
You can find an instructive example of model-based development in my tutorial book Engineering Front-End Web Apps with Plain JavaScript.
This one is in my point of view a duplicate of that other question. It can't be flagged because there is no accepted answer. The related question on meta stackexchange does not provide a clear solution to that situation.
I think my personal answer was relevant and is applicable to the current question.
To be synthetic, Martin Fowler considers current uses of UML. I think he describe the current practices. Perhaps should these evolve ?
Perhaps would the initial question be the right place to discuss ?
I work for a polygot organisation where we code in multiple different languages and architectural styles.
I have been writing Service Orientated Application's for around two years now, and have gotten comfortable with the way I do things, and that's the problem.
At the Big SOA level we all agree on how to use SOA principles to connect different pieces of the solution/enterprise.
At the component level we all differ slightly;
Currently I take the every high level component as a service approach to SOA, favouring capability driven interfaces and softeware fortresses. Be the implemenation beans or wcf services the pattern remains unchanged.
Like so, SOA Design Pattern
Others in my organisation opt for the rich domain model of standard classes underneath a facade.
Architectural styles like SOAP, REST have both been used at this level.
We also differ in the style of method call, command style messages vs more activity descriptive messages.
I have used both and am happy with either, my question are there other methods are other engineers using to compose their SOA.
I am interesed in new ideas, how ever wacky, to stimulate new ways of thinking around the topic of building a SOA.
I spent awhile building up a components-based approach to SOA called SoaKit that might be helpful. See http://bradjcox.blogspot.com for rationale.
The basic idea is to avoid tools-based approaches (JAX-WS) in favor of a suite of pre-built components (provided by SoaKit) that each do commonly-needed functions and can be snapped together easily to do the whole job. Example components: add SAML signed header, decrypt/encrypt message parts, XSLT/XQUERY transforms, and so forth and so on, with each such component independently configurable.
If an enterprise is a city, a service is a house in that city, and SoaKit components are bricks for building houses. The blog has articles that contrast that with the mud-brick approach commonly used today. The analogy is to evoke the impact Roman brick architecture brought to building construction, seeking to bring the same impact to software.
Hope the notion is helpful. Shelved the idea because the world seemed bent on monolithic magic push-button approaches (JAX-WS) that are nearly impossible to control or understand. That's been my experience with JAX-WS/Metro and WSO2 at least.
I have been interested in formal methods for some time. I have used formal methods to reason about some very specific sub-areas of a few projects I have been working on. I was never able to convince other team members to try the same let alone specify an entire domain with a formal method.
One method I have found particularly interesting is Alloy. I think that it may "scale" better as foundation for an entire project because it is conceptually and notationally very close to actual programming languages. Furthermore, the tools are quite solid so that the benefits of model verification are readily available.
I'd be very much interested to hear about any real-world experiences you folks might have had with using Alloy in your projects. Do you feel that it has helped you in designing a better domain model? Did find errors in your domain model during verification? Would you use it again?
I've used Alloy on a few projects and have found it helpful; on some but not all of those projects I have been able to persuade others involved to use Alloy as well, or at least to work with the Alloy models I wrote. These projects may or may not be what you have in mind in asking for 'real-world' projects, but they certainly took place in the part of the real world I work in.
In 2006 and 2007 I created a partial Alloy model for the then-current draft of the W3C XProc specification; as far as I could tell, most members of the working group never read the paper I wrote (at http://www.w3.org/XML/XProc/2006/12/alloy-models/models.html); they said "Oh, we changed that part of the spec last week, so what the model says is no longer relevant". But the paper did manage to persuade the editor of the spec that the abstract 'component' level described in the first draft of the spec was woefully underspecified and needed to be either fully specified or dropped. He dropped it, with (I think) good results for the readability and usability of the spec.
In 2010 I made an Alloy model of the XPath 1.0 data model, which uncovered some glitches in the specification. The reaction of most interested parties (including the W3C working group responsible for maintaining the XPath 1.0 spec) has, unfortunately, not been encouraging.
A research project I'm involved with has used Alloy to model the MLCD Overlap Corpus, a collection of sample documents and related information we are creating (hyperlinks suppressed at SO's insistence); the Alloy model found a couple of errors in our initial design for the corpus catalog, so it was well worth the effort.
And we have also used Alloy to formalize some modeling work we have done on the nature of transcription and on the extension of the type/token distinction to document structure (for our paper, look for the 2010 proceedings of Balisage: The Markup Conference). This lies a little bit outside Alloy's usual area of application, as it has nothing to do with software design, but Alloy's ability to check models for consistency and generate instances has been invaluable in showing us some of the logical consequences of this or that possible axiom for our model.
To answer your specific questions: yes, Alloy has helped me specify cleaner domain models, and yes, it has found errors and glitches. They have often been small, for the reasons Daniel Jackson explains in his book Software Abstractions: first, if you use models during design, you catch errors early, when everything is still small. And, second (in Jackson's words), "In hindsight, most software design issues are trivial."
He continues: "But if you don't address them head-on, trivial issues have a nasty habit of becoming nontrivial." My experience amply confirms this. Much better to head off such problems early. So yes, I will use Alloy again.
Yes, I've used Alloy and it's cousins industrially. Alloy has been most helpful in convincing me that my models weren't wildly wrong---or rather, showing me where they were wrong and gave rise to silly results. Other more specific tools, like Song's Athena and Guttman and Ramsdell's CPSA have been more useful in their narrower domains. What more would you like to hear about?
Belatedly adding to this thread... Eunsuk Kang has recently applied Alloy to perform security analyses of web APIs for some start ups (following many applications of Alloy in security such as Apurva's analysis of OAuth and Barth et al's analysis of browser based security mechanisms for CSRF etc); Pamela Zave has been working on an impressive analysis of Chord, a peer to peer storage system, and has recently written up a fix to the original algorithm.
I am currently trying to draw a set of UML diagrams to represent products, offers, orders, deliveries and payments. These diagrams have probably been invented by a million developers before me.
Are there any efforts to standardize the modeling of such common things? Or even the modeling of specific domains (for example car-manufacturing).
Do you know if there is some sort of repository containing UML diagrams (class diagrams, sequence diagrams, state diagrams...)?
There is a movement for documenting (as opposed to standardizing) models for certain domains. These are called analysis patterns and is a term Martin Fowler came up with. He actually wrote a book called Analysis patterns. Also, he has a dedicated section on his website where he presents some of these patterns accompanied by UML diagrams.
Maybe you'll find some inspiration that will help you in modeling your domain. I've stressed the word inspiration as I think different businesses have different requirements although they operate the same domain so the solutions you might read about may not be appropriate for your problem.
There are many tools out there that do both - but they're generally not free!
Microsoft Visio does both and is extensible. For UML artefacts they come with auto generators into VB/Java template code - but you can modify them to auto-generate any code. There are many users of Visio that have created models from which to use as templates.
Artisan Enterprize is by far the most powerful UML tool (but it's not cheap).
Some would argue that Rational Rose or RUP is the better tool
But for Car-Manufacturing and other similar real world modelling, by far the best tool is Mathworks Simulink (not because it's one of the most expensive). It is by far the best tool beccause you can animate the model - you can prove the model working before generating the slik code (in whatever grammar/language/other Models you care to push it)!
You can obtain a student license for around £180; with the 'real thing' pushing £4000 (for car-related artefacts). The full product with all the trimmings is about £15k. Simulink is also extensible with a C like language though there is a .Net addin and APIs to use a plethora of other langhuages. And, just like Visio there is a world-wide forum creating saleable, shareware & freeware real world model templates. Many world-wide Auto-Manufacturers are already using Simulink.
I think that MiniQuark question is really good and will sooner or later be provided by vendors such as Omondo, Rational IBM etc... Users doesn't just need tools, they need models out of the box and just add their business rules inside an existing well defined architecture. Why to develop from scratch a new architecture if the job has already be done ? In Java we use plenty of frameworks, existing methods etc...so why not to go one level higher and reuse architecture ? It is today impossible to guess how a project will evole and new demands are coming every day. We therefore need a stable architecture which has been tested previously and is extensible. I have seen so many projects starting with a nice architecture then realizing in the middle of the project that this is not what is the best and then changing their architecture. Renaming classes, splitting classes, creating packages etc...after the first iteration it is getting a real mess. Could you imagine what we found after 10 iterations !! a total mess !!
This mess would had been avoided if using a predefined model which has been tested previously because the missing class, or package etc..would have already been created and only a class rename would be sufficient for architecture purposes. Adding business rules methods will end the codding stage before deployment test.
I think there is a confusion between patterns and the initial question which is related to UML model re usability.
There is no today any reusable model out of the box which has been developped. This is really strange but the job has never been done or never been shared.
Omondo has tried to launch an initiative without real success. I have heard that they are working on hundred of out of box models which will be open source and given for free to the community. I hope this will be done because this is really important for me and would save me a lot of time at the beginning of a project.